home *** CD-ROM | disk | FTP | other *** search
/ Chip 1998 September / CHIP Eylül 1998.iso / Slackwar / docs / NET-3-HOWTO < prev    next >
Text File  |  1997-09-02  |  185KB  |  4,320 lines
  1.   Linux NET-3-HOWTO, Linux Networking.
  2.   Terry Dawson, VK2KTJ, terry@perf.no.itg.telstra.com.au
  3.   v1.2, 20 August 1997
  4.  
  5.   The Linux Operating System boasts kernel based networking support
  6.   written almost entirely from scratch. The performance of the tcp/ip
  7.   implementation in recent kernels makes it a worthy alternative to even
  8.   the best of its peers.  This document aims to describe how to install
  9.   and configure the Linux networking software and associated tools.
  10.  
  11.   1.  Changes from the previous version
  12.  
  13.   Additions:
  14.           Reference to PLIP-mini-HOWTO - thanks Claes
  15.           IP NAT - Network Address Translation
  16.  
  17.   Corrections/Updates:
  18.           Many corrections from Alessandro Rubini - thanks!
  19.           Updated Larry Stefani's email address - thanks Larry
  20.           Corrected ftp.linux.uk.org nettools location - thanks Ron
  21.           Corrected incorrect route command - thanks John
  22.           More broken route commands! - thanks Jean-Pierre
  23.           IPv6 addresses are 16 bytes not 32, oops - thanks Erez
  24.  
  25.   ToDo:
  26.           Add traffic shaper
  27.           Describe new routing algorithm
  28.           Add IPv6 kernel compile options
  29.           Describe /proc/sys/net/* entries.
  30.           WanRouter device
  31.  
  32.   2.  Introduction.
  33.  
  34.   The original NET-FAQ was written by Matt Welsh and I to answer
  35.   frequently asked questions about networking for Linux at a time before
  36.   the Linux Documentation Project had formally started. It covered the
  37.   very early development versions of the Linux Networking Kernel. The
  38.   NET-2-HOWTO superceded the NET-FAQ and was one of the original LDP
  39.   HOWTO documents, it covered what was called version 2 and later
  40.   version 3 of the Linux kernel Networking software. This document in
  41.   turn supercedes it and relates only to version 3 of the Linux
  42.   Networking Kernel.
  43.  
  44.   Previous versions of this document became quite large because of the
  45.   enormous amount of material that fell within its scope. To help reduce
  46.   this problem a number of HOWTO's dealing with specific networking
  47.   topics have been produced. This document will provide pointers to them
  48.   where relevant and cover those areas not yet covered by other
  49.   documents.
  50.  
  51.   2.1.  Feedback
  52.  
  53.   I always appreciate feedback and especially value contributions.
  54.   Please direct any feedback or contributions to me by email
  55.   <mailto:terry@perf.no.itg.telstra.com.au>.
  56.  
  57.   3.  How to use this HOWTO document (NET-3-HOWTO-HOWTO ?).
  58.  
  59.   The format of this document is differs from earlier versions. I've now
  60.   regrouped the sections so that there is informative material at the
  61.   beginning which you can skip if you are not interested, generic
  62.   material next which you must ensure you understand before proceeding
  63.   to the technology specific sections in the rest of the document.
  64.  
  65.      Read the generic sections
  66.         These sections apply to every, or nearly every, technology
  67.         described later and so are very important for you to understand.
  68.  
  69.      Consider your network
  70.         You should know how your network is, or will be, designed and
  71.         exactly what hardware and technology types you will be
  72.         implementing.
  73.  
  74.      Read the technology specific sections related to your requirements
  75.         When you know what you want you can address each component in
  76.         turn. These sections cover only details specific to a particular
  77.         technology.
  78.  
  79.      Do the configuration work
  80.         You should actually try to configure your network and take
  81.         careful note of any problems you have.
  82.  
  83.      Look for further help if needed
  84.         If you experience problems that this document does not help you
  85.         to resolve then read the section related to where to get help or
  86.         where to report bugs.
  87.  
  88.      Have fun!
  89.         Networking is fun, enjoy it.
  90.  
  91.   4.  General Information about Linux Networking.
  92.  
  93.   4.1.  A brief history of Linux Networking Kernel Development.
  94.  
  95.   Developing a brand new kernel implementation of the tcp/ip protocol
  96.   stack that would perform as well as existing implementations was not
  97.   an easy task.  The decision not to port one of the existing
  98.   implementations was made at a time when there was some uncertainty as
  99.   to whether the existing implementations may become encumbered by
  100.   restrictive copyrights because of the court case put by U.S.L. and
  101.   when there was a lot of fresh enthusiasm for doing it differently and
  102.   perhaps even better than had already been done.
  103.  
  104.   The original volunteer to lead development of the kernel network code
  105.   was Ross Biro <biro@yggdrasil.com>. Ross produced a simple and
  106.   incomplete but mostly usable implementation set of routines that were
  107.   complemented by an ethernet driver for the WD-8003 network interface
  108.   card.  This was enough to get many people testing and experimenting
  109.   with the software and some people even managed to connect machines in
  110.   this configuration to live internet connections. The pressure within
  111.   the Linux community driving development for networking support was
  112.   building and eventually the cost of a combination of some unfair
  113.   pressure applied to Ross and his own personal commitments outweighed
  114.   the benefit he was deriving and he stepped down as lead developer.
  115.   Ross's efforts in getting the project started and accepting the
  116.   responsibility for actually producing something useful in such
  117.   controversial circumstances were what catalysed all future work and
  118.   were therefore an essential component of the success of the current
  119.   product.
  120.  
  121.   Orest Zborowski <obz@Kodak.COM> produced the original BSD socket
  122.   programming interface for the Linux kernel. This was a big step
  123.   forward as it allowed many of the existing network applications to be
  124.   ported to linux without serious modification.
  125.  
  126.   Somewhere about this time Laurence Culhane <loz@holmes.demon.co.uk>
  127.   developed the first drivers for Linux to support the SLIP protocol.
  128.   These enabled many people who did not have access to Ethernet
  129.   networking to experiment with the new networking software. Again, some
  130.   people took this driver and pressed it into service to connect them to
  131.   the Internet. This gave many more people a taste of the possibilities
  132.   that could be realised if Linux had full networking support and grew
  133.   the number of users actively using and experimenting with the
  134.   networking software that existed.
  135.  
  136.   One of the people that had also been actively working on the task of
  137.   building networking support was Fred van Kempen
  138.   <waltje@uwalt.nl.mugnet.org>.  After a period of some uncertainty
  139.   following Ross's resignation from the lead developer position Fred
  140.   offered his time and effort and accepted the role essentially
  141.   unopposed. Fred had some ambitious plans for the direction that he
  142.   wanted to take the Linux networking software and he set about
  143.   progressing in those directions. Fred produced a series of networking
  144.   code called the `NET-2' kernel code (the `NET' code being Ross's)
  145.   which many people were able to use pretty much usefully. Fred formally
  146.   put a number of innovations on the development agenda, such as the
  147.   dynamic device interface, Amateur Radio AX.25 protocol support and a
  148.   more modularly designed networking implementation.  Fred's NET-2 code
  149.   was used by a fairly large number of enthusiasts, the number
  150.   increasing all the time as word spread that the software was working.
  151.   The networking software at this time was still a large number of
  152.   patches to the standard release of kernel code and was not included in
  153.   the normal release.  The NET-FAQ and subsequent NET-2-HOWTO's
  154.   described the then fairly complex procedure to get it all working.
  155.   Fred's focus was on developing innovations to the standard network
  156.   implementations and this was taking time. The community of users was
  157.   growing impatient for something that worked reliably and satisfied the
  158.   80% of users and, as with Ross, the pressure on Fred as lead developer
  159.   rose.
  160.  
  161.   Alan Cox <iialan@www.uk.linux.org> proposed a solution to the problem
  162.   designed to resolve the situation. He proposed that he would take
  163.   Fred's NET-2 code and debug it, making it reliable and stable so that
  164.   it would satisfy the impatient user base while relieving that pressure
  165.   from Fred allowing him to continue his work. Alan set about doing
  166.   this, with some good success and his first version of Linux networking
  167.   code was called `Net-2D(ebugged)'. The code worked reliably in many
  168.   typical configurations and the user base was happy. Alan clearly had
  169.   ideas and skills of his own to contribute to the project and many
  170.   discussions relating to the direction the NET-2 code was heading
  171.   ensued. There developed two distinct schools within the Linux
  172.   networking community, one that had the philosophy of `make it work
  173.   first, then make it better' and the other of `make it better first'.
  174.   Linus ultimately arbitrated and offered his support to Alan's
  175.   development efforts and included Alan's code in the standard kernel
  176.   source distribution.  This placed Fred in a difficult position. Any
  177.   continued development would lack the large user base actively using
  178.   and testing the code and this would mean progress would be slow and
  179.   difficult. Fred continued to work for a short time and eventually
  180.   stood down and Alan came to be the new leader of the Linux networking
  181.   kernel development effort.
  182.  
  183.   Donald Becker <becker@cesdis.gsfc.nasa.gov> soon revealed his talents
  184.   in the low level aspects of networking and produced a huge range of
  185.   ethernet drivers, nearly all of those included in the current kernels
  186.   were developed by Donald. There have been other people that have made
  187.   significant contributions, but Donald's work is prolific and so
  188.   warrants special mention.
  189.  
  190.   Alan continued refining the NET-2-Debugged code for some time while
  191.   working on progressing some of the matters that remained unaddressed
  192.   on the `TODO' list.  By the time the Linux 1.3.* kernel source had
  193.   grown its teeth the kernel networking code had migrated to the NET-3
  194.   release on which current versions are based. Alan worked on many
  195.   different aspects of the networking code and with the assistance of a
  196.   range of other talented people from the Linux networking community
  197.   grew the code in all sorts of directions. Alan produced dynamic
  198.   network devices and the first standard AX.25 and IPX implementations.
  199.   Alan has continued tinkering with the code, slowly restructuring and
  200.   enhancing it to the state it is in today.
  201.  
  202.   PPP support was added by Michael Callahan <callahan@maths.ox.ac.uk>
  203.   and Al Longyear <longyear@netcom.com> this too was critical to
  204.   increasing the number of people actively using linux for networking.
  205.  
  206.   Jonathon Naylor <jsn@cs.nott.ac.uk> has contributed by significantly
  207.   enhancing Alan's AX.25 code, adding NetRom and Rose protocol support.
  208.   The AX.25/NetRom/Rose support itself is quite significant, because no
  209.   other operating system can boast standard native support for these
  210.   protocols beside Linux.
  211.  
  212.   There have of course been hundreds of other people who have made
  213.   significant contribution to the development of the Linux networking
  214.   software. Some of these you will encounter later in the technology
  215.   specific sections, other people have contributed modules, drivers,
  216.   bug-fixes, suggestions, test reports and moral support. In all cases
  217.   each can claim to have played a part and offered what they could. The
  218.   Linux kernel networking code is an excellent example of the results
  219.   that can be obtained from the Linux style of anarchic development, if
  220.   it hasn't yet surprised you, it is bound to soon enough, the
  221.   development hasn't stopped.
  222.  
  223.   4.2.  Where to get other information about Linux Networking.
  224.  
  225.   There are a number of places where you can find good information about
  226.   Linux networking.
  227.  
  228.   Alan Cox, the current maintainer of the Linux kernel networking code
  229.   maintains a world wide web page that contains highlights of current
  230.   and new developments in linux Networking at: www.uk.linux.org
  231.   <http://www.uk.linux.org/NetNews.html>.
  232.  
  233.   Another good place is a book written by Olaf Kirch entitled the
  234.   Network Administrators Guide. It is a work of the Linux
  235.   Documentatation Project <http://sunsite.unc.edu/LDP/> and you can read
  236.   it interactively at Network Administrators Guide HTML version
  237.   <http://sunsite.unc.edu/LDP/LDP/nag/nag.html> or you can obtain it in
  238.   various formats by ftp from the sunsite.unc.edu LDP ftp archive
  239.   <ftp://sunsite.unc.edu/pub/Linux/docs/LDP/network-guide/>. Olaf's book
  240.   is quite comprehensive and provides a good high level overview of
  241.   network configuration under linux.
  242.  
  243.   There is a newsgroup in the Linux news heirarchy dedicated to
  244.   networking and related matters, it is: comp.os.linux.networking
  245.   <news:comp.os.linux.networking>
  246.  
  247.   There is a mailing list to which you can subscribe where you may ask
  248.   questions relating to Linux networking. To subscribe you should send a
  249.   mail message:
  250.  
  251.   To: majordomo@vger.rutgers.edu
  252.   Subject: anything at all
  253.   Message:
  254.  
  255.   subscribe linux-net
  256.  
  257.   On the various IRC networks there are often #linux channels on which
  258.   people will be able to answer questions on linux networking.
  259.  
  260.   Please remember when reporting any problem to include as much relevant
  261.   detail about the problem as you can. Specifically you should specify
  262.   the versions of software that you are using, especially the kernel
  263.   version, the version of tools such as pppd or dip and the exact nature
  264.   of the problem you are experiencing. This means taking note of the
  265.   exact syntax of any error messages you receive and of any commands
  266.   that you are issuing.
  267.  
  268.   4.3.  Where to get some non-linux-specific network information.
  269.  
  270.   If you are after some basic tutorial information on tcp/ip networking
  271.   generally, then I recommend you take a look at the following
  272.   documents:
  273.  
  274.      tcp/ip introduction
  275.         this document comes as both a text version
  276.         <ftp://athos.rutgers.edu/runet/tcp-ip-intro.doc> and a
  277.         postscript version <ftp://athos.rutgers.edu/runet/tcp-ip-
  278.         intro.ps>.
  279.  
  280.      tcp/ip administration
  281.         this document comes as both a text version
  282.         <ftp://athos.rutgers.edu/runet/tcp-ip-admin.doc> and a
  283.         postscript version <ftp://athos.rutgers.edu/runet/tcp-ip-
  284.         admin.ps>.
  285.  
  286.   If you are after some more detailed information on tcp/ip networking
  287.   then I highly recommend:
  288.  
  289.        "Internetworking with TCP/IP"
  290.        by Douglas E. Comer
  291.  
  292.        ISBN 0-13-474321-0
  293.        Prentice Hall publications.
  294.  
  295.   If you are wanting to learn about how to write network applications in
  296.   a Unix compatible environment then I also highly recommend:
  297.  
  298.        "Unix Network Programming"
  299.        by W. Richard Stevens
  300.  
  301.        ISBN 0-13-949876-1
  302.        Prentice Hall publications.
  303.  
  304.   You might also try the comp.protocols.tcp-ip <news:comp.protocols.tcp-
  305.   ip> newsgroup.
  306.  
  307.   An important source of specific technical information relating to the
  308.   Internet and the tcp/ip suite of protocols are RFC's. RFC is an
  309.   acronym for `Request For Comment' and is the standard means of
  310.   submitting and documenting Internet protocol standards. There are many
  311.   RFC repositories. Many of these sites are ftp sites and other provide
  312.   World Wide Web access with an associated search engine that allows you
  313.   to search the RFC database for particular keywords.
  314.  
  315.   One possible source for RFC's is at: Nexor RFC database
  316.   <http://pubweb.nexor.co.uk/public/rfc/index/rfc.html>.
  317.  
  318.   5.  Generic Network Configuration Information.
  319.  
  320.   The following subsections you will pretty much need to know and
  321.   understand before you actually try to configure your network. They are
  322.   fundamental principles that apply regardless of the exact nature of
  323.   the network you wish to deploy.
  324.  
  325.   5.1.  What do I need to start ?
  326.  
  327.   Before you start building or configuring your network you will need
  328.   some things. The most important of these are:
  329.  
  330.   5.1.1.  Current Kernel source.
  331.  
  332.   Because the kernel you are running now might not yet have support for
  333.   the network types or cards that you wish to use you will probably need
  334.   the kernel source so that you can recompile the kernel with the
  335.   appropriate options.
  336.  
  337.   You can always obtain the latest kernel source from: ftp.funet.fi
  338.   <ftp://ftp.funet.fi/pub/Linux/PEOPLE/Linus/v2.0>.
  339.  
  340.   Normally the kernel source will be untarred into the /usr/src/linux
  341.   directory. For information on how to apply patches and build the
  342.   kernel you should read the Kernel-HOWTO <Kernel-HOWTO.html>.  For
  343.   information on how to configure kernel modules you should read the
  344.   Module-HOWTO <Module-HOWTO.html>.
  345.  
  346.   Unless specifically stated otherwise, I recommend you stick with the
  347.   standard kernel release (the one with the even number as the second
  348.   digit in the version number). Development release kernels (the ones
  349.   with the odd second digit) may have structural or other changes that
  350.   may cause problems working with the other software on your system. If
  351.   you are uncertain that you could resolve those sorts of problems in
  352.   addition to the potential for there being other software errors, then
  353.   don't use them.
  354.  
  355.   5.1.2.  Current Network tools.
  356.  
  357.   The network tools are the programs that you use to configure linux
  358.   network devices. These tools allow you to assign addresses to devices
  359.   and configure routes for example.
  360.  
  361.   Most modern linux distributions are supplied with the network tools,
  362.   so if you have installed from a distribution and haven't yet installed
  363.   the network tools then you should do so.
  364.  
  365.   If you haven't installed from a distribution then you will need to
  366.   source and compile the tools yourself. This isn't difficult.
  367.  
  368.   The network tools are now maintained by Bernd Eckenfels and are
  369.   available at: ftp.inka.de
  370.   <ftp://ftp.inka.de/pub/comp/Linux/networking/NetTools/> and are
  371.   mirrored at: ftp.uk.linux.org
  372.   <ftp://ftp.uk.linux.org/pub/linux/Networking/base/>.
  373.  
  374.   Be sure to choose the version that is most appopriate for the kernel
  375.   you wish to use and follow the instructions in the package to install.
  376.  
  377.   To install and configure the version current at the time of the
  378.   writing you need do the following:
  379.  
  380.   #
  381.   # cd /usr/src
  382.   # tar xvfz net-tools-1.33.tar.gz
  383.   # cd net-tools-1.33
  384.   # make config
  385.   # make
  386.   # make install
  387.   #
  388.  
  389.   Additionally, if you intend configuring a firewall or using the IP
  390.   masquerade feature you will require the ipfwadm command. The latest
  391.   version of it may be obtained from: ftp.xos.nl
  392.   <ftp:/ftp.xos.nl/pub/linux/ipfwadm>. Again there are a number of
  393.   versions available. Be sure to pick the version that most closely
  394.   matches your kernel.
  395.  
  396.   To install and configure the version current at the time of the
  397.   writing you need do the following:
  398.  
  399.   #
  400.   # cd /usr/src
  401.   # tar xvfz ipfwadm-2.3.0.tar.gz
  402.   # cd ipfwadm-2.3.0
  403.   # make
  404.   # make install
  405.   #
  406.  
  407.   5.1.3.  Network Application Programs.
  408.  
  409.   The network application programs are programs such as telnet and ftp
  410.   and their respective server programs. David Holland
  411.   <dholland@hcs.harvard.edu> now manages a distribution of the most
  412.   common of these. You may obtain it from: ftp.uk.linux.org
  413.   <ftp://ftp.uk.linux.org/pub/linux/Networking/base>.
  414.  
  415.   To install and configure the version current at the time of the
  416.   writing you need do the following:
  417.  
  418.   #
  419.   # cd /usr/src
  420.   # tar xvfz /pub/net/NetKit-B-0.08.tar.gz
  421.   # cd NetKit-B-0.08
  422.   # more README
  423.   # vi MCONFIG
  424.   # make
  425.   # make install
  426.   #
  427.  
  428.   5.1.4.  Addresses.
  429.  
  430.   Internet Protocol Addresses are composed of four bytes. The convention
  431.   is to write addresses in what is called `dotted decimal notation'. In
  432.   this form each byte is converted to a decimal number (0-255) dropping
  433.   any leading zero's unless the number is zero and written with each
  434.   byte seperated by a `.' character. By convention each interface of a
  435.   host or router has an IP address. It is legal for the same IP address
  436.   to be used on each interface of a single machine in some circumstances
  437.   but usually each interface will have its own address.
  438.  
  439.   Internet Protocol Networks are contiguous sequences of IP addresses.
  440.   All addresses within a network have a number of digits within the
  441.   address in common. The portion of the address that is common amongst
  442.   all addresses within the network is called the `network portion' of
  443.   the address. The remaining digits are called the `host portion'. The
  444.   number of bits that are shared by all addresses within a network is
  445.   called the netmask and it is role of the netmask to determine which
  446.   addresses belong to the network it is applied to and which don't. For
  447.   example, consider the following:
  448.  
  449.   -----------------  ---------------
  450.   Host Address       192.168.110.23
  451.   Network Mask       255.255.255.0
  452.   Network Portion    192.168.110.
  453.   Host portion                  .23
  454.   -----------------  ---------------
  455.   Network Address    192.168.110.0
  456.   Broadcast Address  192.168.110.255
  457.   -----------------  ---------------
  458.  
  459.   Any address that is 'bitwise anded' with its netmask will reveal the
  460.   address of the network it belongs to. The network address is therefore
  461.   always the lowest numbered address within the range of addresses on
  462.   the network and always has the host portion of the address coded all
  463.   zeroes.
  464.  
  465.   The broadcast address is a special address that every host on the
  466.   network listens to in addition to its own unique address. This address
  467.   is the one thhat datagrams are sent to if every host on the network is
  468.   meant to receive it. Certain types of data like routing information
  469.   and warning messages are transmitted to the broadcast address so that
  470.   every host on the network can receive it simultaneously. There are two
  471.   commonly used standards for what the broadcast address should be. The
  472.   most widely accepted one is to use the highest possible address on the
  473.   network as the broadcast address.  In the example above this would be
  474.   192.168.110.255. For some reason other sites have adopted the
  475.   convention of using the network address as the broadcast address. In
  476.   practice it doesn't matter very much which you use but you must make
  477.   sure that every host on the network is configured with the same
  478.   broadcast address.
  479.  
  480.   For administrative reasons some time early in the development of the
  481.   IP protocol some arbitrary groups of addresses were formed into
  482.   networks and these networks were grouped into what are called classes.
  483.   These classes provide a number of standard size networks that could be
  484.   allocated. The ranges allocated are:
  485.  
  486.   ----------------------------------------------------------
  487.   | Network | Netmask       | Network Addresses            |
  488.   | Class   |               |                              |
  489.   ----------------------------------------------------------
  490.   |    A    | 255.0.0.0     | 0.0.0.0    - 127.255.255.255 |
  491.   |    B    | 255.255.0.0   | 128.0.0.0  - 191.255.255.255 |
  492.   |    C    | 255.255.255.0 | 192.0.0.0  - 223.255.255.255 |
  493.   |Multicast| 240.0.0.0     | 224.0.0.0  - 239.255.255.255 |
  494.   ----------------------------------------------------------
  495.  
  496.   What addresses you should use depends on exactly what it is that you
  497.   are doing. You may have to use a combination of the following
  498.   activities to get all the addresses you need:
  499.  
  500.      Installing a linux machine on an existing IP network
  501.         If you wish to install a linux machine onto an existing IP
  502.         network then you should contact whoever administers the network
  503.         and ask them for the following information:
  504.  
  505.      ╖  Host IP Address
  506.  
  507.      ╖  IP network address
  508.  
  509.      ╖  IP broadcast address
  510.  
  511.      ╖  IP netmask
  512.  
  513.      ╖  Router address
  514.  
  515.      ╖  Domain Name Server Address
  516.  
  517.         You should then configure your linux network device with those
  518.         details.  You can not make them up and expect your configuration
  519.         to work.
  520.  
  521.      Building a brand new network that will never connect to the Inter¡
  522.         net
  523.         If you are building a private network and you never intend that
  524.         network to be connected to the Internet then you can choose
  525.         whatever addresses you like.  However, for safety and
  526.         consistency reasons there have been some IP network addresses
  527.         that have been reserved specifically for this purpose. These are
  528.         specified in RFC1597 and are as follows:
  529.  
  530.         -----------------------------------------------------------
  531.         |         RESERVED PRIVATE NETWORK ALLOCATIONS            |
  532.         -----------------------------------------------------------
  533.         | Network | Netmask       | Network Addresses             |
  534.         | Class   |               |                               |
  535.         -----------------------------------------------------------
  536.         |    A    | 255.0.0.0     | 10.0.0.0    - 10.255.255.255  |
  537.         |    B    | 255.255.0.0   | 172.16.0.0  - 172.31.255.255  |
  538.         |    C    | 255.255.255.0 | 192.168.0.0 - 192.168.255.255 |
  539.         -----------------------------------------------------------
  540.  
  541.      You should first decide how large you want your network to be and
  542.      then choose as many of the addresses as you require.
  543.  
  544.   5.2.  Where should I put the configuration commands ?
  545.  
  546.   There are a few different approaches to Linux system boot procedures.
  547.   After the kernel boots, it always executes a program called `init'.
  548.   The init program then reads its configuration file called /etc/inittab
  549.   and commences the boot process. There are a few different flavours of
  550.   init and it is this variation that is the largest cause of variation
  551.   between distributions or machines.
  552.  
  553.   Usually the /etc/inittab file contains an entry looking something
  554.   like:
  555.  
  556.        si::sysinit:/etc/init.d/boot
  557.  
  558.   This line specifies the name of the shell script file that actually
  559.   manages the boot sequence. This file is somewhat equivalent to the
  560.   AUTOEXEC.BAT file in MS-DOS.
  561.  
  562.   There are usually other scripts that are called by the boot script and
  563.   often the network is configured within one of many of these.
  564.  
  565.   The following table may be used as a guide for your system:
  566.  
  567.   -------------------------------------------------------------------------------
  568.   Distrib. |Interface Config/Routing                    |Server Initialisation
  569.   -------------------------------------------------------------------------------
  570.   Debian   |/etc/init.d/network                         |/etc/init.d/netbase
  571.            |                                            |/etc/init.d/netstd_init
  572.            |                                            |/etc/init.d/netstd_nfs
  573.            |                                            |/etc/init.d/netstd_misc
  574.   -------------------------------------------------------------------------------
  575.   Slackware|/etc/rc.d/rc.inet1                          |/etc/rc.d/rc.inet2
  576.   -------------------------------------------------------------------------------
  577.   RedHat   |/etc/sysconfig/network-scripts/ifup-<ifname>|/etc/rc.d/init.d/network
  578.   -------------------------------------------------------------------------------
  579.  
  580.   Most modern distributions include a program that will allow you to
  581.   configure many of the common sorts of network interfaces. If you have
  582.   one of these then you should see if it will do what you want before
  583.   attempting a manual configuration.
  584.  
  585.        -----------------------------------------
  586.        Distrib   | Network configuration program
  587.        -----------------------------------------
  588.        RedHat    | /sbin/netcfg
  589.        Slackware | /sbin/netconfig
  590.        -----------------------------------------
  591.  
  592.   5.3.  Creating your network interfaces.
  593.  
  594.   In many Unix operating systems the network devices have appearances in
  595.   the /dev directory. This is not so in Linux. In Linux the network
  596.   devices are created dynamically in software and thus do not require
  597.   device files to be present.
  598.  
  599.   In the majority of cases the network devices is automatically created
  600.   by the device driver while it is initialising and has located your
  601.   hardware. For example, the ethernet device driver creates eth[0..n]
  602.   interfaces sequentially as it locates your ethernet hardware. The
  603.   first ethernet card found becomes eth0, the second eth1 etc.
  604.  
  605.   In some cases though, notably slip and ppp, the network devices are
  606.   created through the action of some user program. The same sequential
  607.   device numbering applies, but the devices are not created
  608.   automatically at boot time. The reason for this is that unlike
  609.   ethernet devices, the number of active slip or ppp devices may vary
  610.   during the uptime of the machine. These cases will be covered in more
  611.   detail in later sections.
  612.  
  613.   5.4.  Configuring a network interface.
  614.  
  615.   When you have all of the programs you need and your address and
  616.   network information you can configure your network interfaces. When we
  617.   talk about configuring a network interface we are talking about the
  618.   process of assigning appropriate addresses to a network device and to
  619.   setting appropriate values for other configurable paramaters of a
  620.   network device. The program most commonly used to do this is the
  621.   ifconfig (interface configure) command.
  622.  
  623.   Typically you would use a command similar to the following:
  624.  
  625.        # ifconfig eth0 192.168.0.1 netmask 255.255.255.0 up
  626.  
  627.   In this case I'm configuring an ethernet interface `eth0' with the IP
  628.   address `192.168.0.1' and a network mask of `255.255.255.0'.  The `up'
  629.   that trails the command tells the interface that it should become
  630.   active.
  631.  
  632.   The kernel assumes certain defaults when configuring interfaces. For
  633.   example, you may specify the network address and broadcast address for
  634.   an interface, but if you don't, as in my example above, then the
  635.   kernel will make reasonable guesses as to what they should be based on
  636.   the netmask you supply and if you don't supply a netmask then on the
  637.   network class of the IP address configured.  In my example the kernel
  638.   would assume that it is a class-C network being configured on the
  639.   interface and configure a network address of `192.168.0.0' and a
  640.   broadcast address of `192.168.0.255' for the interface.
  641.   There are many other options to the ifconfig command. The most
  642.   important of these are:
  643.  
  644.      up this option activates an interface.
  645.  
  646.      down
  647.         this option deactivates an interface.
  648.  
  649.      [-]arp
  650.         this option enables or disables use of the address resolution
  651.         protocol on this interface
  652.  
  653.      [-]allmulti
  654.         this option enables or disables the reception of all hardware
  655.         multicast packets. Hardware multicast enables groups of hosts to
  656.         receive packets addressed to special destinations. This may be
  657.         of importance if you are using applications like desktop
  658.         videoconferencing but is normally not used.
  659.  
  660.      mtu N
  661.         this parameter allows you to set the MTU of this device.
  662.  
  663.      netmask addr
  664.         this parameter allows you to set the network mask of the network
  665.         this device belongs to.
  666.  
  667.      irq addr
  668.         this parameter only works on certain types of hardware and
  669.         allows you to set the IRQ of the hardware of this device.
  670.  
  671.      [-]broadcast [addr]
  672.         this parameter allows you to enable and set the accepting of
  673.         datagrams destined to the broadcast address, or to disable
  674.         reception of these datagrams.
  675.  
  676.      [-]pointopoint [addr]
  677.         this parameter allows you to set the address of the machine at
  678.         the remote end of a point to point link such as for slip or ppp.
  679.  
  680.      hw <type> <addr>
  681.         this parameter allows you to set the hardware address of certain
  682.         types of network devices. This is not often useful for ethernet,
  683.         but is useful for other network types such as AX.25.
  684.  
  685.   You may use the ifconfig command on any network interface. Some user
  686.   programs such as pppd and dip automatically configure the network
  687.   devices as they create them, so manual use of ifconfig is unnecessary.
  688.  
  689.   5.5.  Configuring your Name Resolver.
  690.  
  691.   The `Name Resolver' is a part of the linux standard library. Its prime
  692.   function is to provide a service to convert human-friendly hostnames
  693.   like `ftp.funet.fi' into machine friendly IP addresses such as
  694.   128.214.248.6.
  695.  
  696.   5.5.1.  What's in a name ?
  697.  
  698.   You will probably be familiar with the appearance of Internet host
  699.   names, but may not understand how they are constructed, or
  700.   deconstructed. Internet domain names are heirarchial in nature, that
  701.   is, they have a tree-like structure. A `domain' is a family, or group
  702.   of names. A `domain' may be broken down into `subdomain'. A `toplevel
  703.   domain' is a domain that is not a subdomain. The Top Level Domains are
  704.   specified in RFC-920. Some examples of the most common top level
  705.   domains are:
  706.  
  707.      COM
  708.         Commercial Organisations
  709.  
  710.      EDU
  711.         Educational Organisations
  712.  
  713.      GOV
  714.         Government Organisations
  715.  
  716.      MIL
  717.         Millitary Organisations
  718.  
  719.      ORG
  720.         Other organisations
  721.  
  722.      Country Designator
  723.         these are two letters codes that represent a particular country.
  724.  
  725.   Each of these top level domains has subdomains. The top level domains
  726.   based on country name are used next broken down into subdomains based
  727.   on the com, edu, gov, mil and org domains. So for example you end up
  728.   with: com.au and gov.au for commercial and government organisations in
  729.   Australia. For historical reasons most domains belonging to one of the
  730.   non-country based top level domains are for organisations within the
  731.   United States, although the United States also has its own country
  732.   code `.us'.
  733.  
  734.   The next level of division usually represents the name of the
  735.   organisation.  Further subdomains vary in nature, often the next level
  736.   of subdomain is based on the departmental structure of the
  737.   organisation but it may be based on any criterion considered
  738.   reasonable and meaningful by the network adminstrators for the
  739.   organisation.
  740.  
  741.   The very left-most portion of the name is always the unique name
  742.   assigned to the host machine and is called the `hostname', the portion
  743.   of the name to the right of the hostname is called the `domainname'
  744.   and the complete name is called the `Fully Qualified Domain Name'.
  745.  
  746.   To use my own email host as an example, the fully qualified domain
  747.   name is `perf.no.itg.telstra.com.au'. This means that the host name is
  748.   `perf' and the domain name is `no.itg.telstra.com.au'. The domain name
  749.   is based on a top level domain based on my country, Australia and as
  750.   my email address belongs to a commercial organisation we have `.com'
  751.   as the next level domain. The name of the company is (was) `telstra'
  752.   and our internal naming structure is based on organisational
  753.   structure, in my case, my machine belongs to the Information
  754.   Technology Group, Network Operations section.
  755.  
  756.   5.5.2.  What information you will need.
  757.  
  758.   You will need to know what domain your hosts name will belong to. The
  759.   name resolver software provides this name translation service by
  760.   making requests to a `Domain Name Server', so you will need to know
  761.   the IP address of a local nameserver that you can use.
  762.  
  763.   There are three files you need to edit, I'll cover each of these in
  764.   turn.
  765.  
  766.   5.5.3.  /etc/resolv.conf
  767.  
  768.   The /etc/resolv.conf is the main configuration file for the name
  769.   resolver code. Its format is quite simple. It is a text file with one
  770.   keyword per line. There are three keywords typically used, they are:
  771.  
  772.      domain
  773.         this keyword specifies the local domain name.
  774.  
  775.      search
  776.         this keyword specifies a list of alternate domain names to
  777.         search for a hostname
  778.  
  779.      nameserver
  780.         this keyword, which may be used many times, specifies an IP
  781.         address of a domain name server to query when resolving names
  782.  
  783.   An example /etc/resolv.conf might look something like:
  784.  
  785.        domain maths.wu.edu.au
  786.        search maths.wu.edu.au wu.edu.au
  787.        nameserver 192.168.10.1
  788.        nameserver 192.168.12.1
  789.  
  790.   This example specifies that the default domain name to append to
  791.   unqualified names (ie hostnames supplied without a domain) is
  792.   maths.wu.edu.au and that if the host is not found in that domain to
  793.   also try the wu.edu.au domain directly. Two nameservers entry are sup¡
  794.   plied, each of which may be called upon by the name resolver code to
  795.   resolve the name.
  796.  
  797.   5.5.4.  /etc/host.conf
  798.  
  799.   The /etc/host.conf file is where you configure some items that govern
  800.   the behaviour of the name resolver code. The format of this file is
  801.   described in detail in the `resolv+' man page. In nearly all
  802.   circumstances the following example will work for you:
  803.  
  804.        order hosts,bind
  805.        multi on
  806.  
  807.   This configuration tells the name resolver to check the /etc/hosts
  808.   file before attempting to query a nameserver and to return all valid
  809.   addresses for a host found in the /etc/hosts file instead of just the
  810.   first.
  811.  
  812.   5.5.5.  /etc/hosts
  813.  
  814.   The /etc/hosts file is where you put the name and IP address of local
  815.   hosts. If you place a host in this file then you do not need to query
  816.   the domain name server to get its IP Address. The disadvantage of
  817.   doing this is that you must keep this file up to date yourself if the
  818.   IP address for that host changes. In a well managed system the only
  819.   hostnames that usually appear in this file are an entry for the
  820.   loopback interface and the local hosts name.
  821.  
  822.        # /etc/hosts
  823.        127.0.0.1      localhost loopback
  824.        192.168.0.1    this.host.name
  825.  
  826.   You may specify more than one host name per line as demonstrated by
  827.   the first entry, which is a standard entry for the loopback interface.
  828.  
  829.   5.6.  Configuring your loopback interface.
  830.  
  831.   The `loopback' interface is a special type of interface that allows
  832.   you to make connections to yourself. There are various reasons why you
  833.   might want to do this, for example, you may wish to test some network
  834.   software without interfering with anybody else on your network. By
  835.   convention the IP address `127.0.0.1' has been assigned specifically
  836.   for loopback. So no matter what machine you go to, if you open a
  837.   telnet connection to 127.0.0.1 you will always reach the local host.
  838.  
  839.   Configuring the loopback interface is simple and you should ensure you
  840.   do.
  841.  
  842.        # ifconfig lo 127.0.0.1
  843.        # route add -host 127.0.0.1 lo
  844.  
  845.   We'll talk more about the route command in the next section.
  846.  
  847.   5.7.  Routing.
  848.  
  849.   Routing is a big topic. It is easily possible to write large volumes
  850.   of text about it. Most of you will have fairly simple routing
  851.   requirements, some of you will not. I will cover some basic
  852.   fundamentals of routing only.  If you are interested in more detailed
  853.   information then I suggest you refer to the references provided at the
  854.   start of the document.
  855.  
  856.   Let's start with a definition. What is IP routing ? Here is one that
  857.   I'm using:
  858.  
  859.        IP Routing is the process by which a host with multiple net¡
  860.        work connections decides where to deliver IP datagrams it
  861.        has received.
  862.  
  863.   It might be useful to illustrate this with an example. Imagine a
  864.   typical office router, it might have a PPP link off the Internet, a
  865.   number of ethernet segments feeding the workstations and another PPP
  866.   link off to another office. When the router receives a datagram on any
  867.   of its network connections, routing is the mechanism that it uses to
  868.   determine which interface it should send the datagram to next. Simple
  869.   hosts also need to route, all Internet hosts have two network devices,
  870.   one is the loopback interface described above and the other is the one
  871.   it uses to talk to the rest of the network, perhaps an ethernet,
  872.   perhaps a PPP or SLIP serial interface.
  873.  
  874.   Ok, so how does routing work ? Each host keeps a special list of
  875.   routing rules, called a routing table. This table contains rows which
  876.   typically contain at least three fields, the first is a destination
  877.   address, the second is the name of the interface to which the datagram
  878.   is to be routed and the third is optionally the IP address of another
  879.   machine which will carry the datagram on its next step through the
  880.   network. In linux you can see this table by using the following
  881.   command:
  882.  
  883.        # cat /proc/net/route
  884.  
  885.   or by using either of the following commands:
  886.  
  887.        # /sbin/route -n
  888.        # /bin/netstat -r
  889.  
  890.   The routing process is fairly simple: an incoming datagram is
  891.   received, the destination address (who it is for) is examined and
  892.   compared with each entry in the table. The entry that best matches
  893.   that address is selected and the datagram is forwarded to the
  894.   specified interface. If the gateway field is filled then the datagram
  895.   is forwarded to that host via the specified interface, otherwise the
  896.   destination address is assumed to be on the network supported by the
  897.   interface.
  898.  
  899.   To manipulate this table a special command is used. This command takes
  900.   command line arguments and converts them into kernel system calls that
  901.   request the kernel to add, delete or modify entries in the routing
  902.   table.  The command is called `route'.
  903.  
  904.   A simple example. Imagine you have an ethernet network. You've been
  905.   told it is a class-C network with an address of 192.168.1.0. You've
  906.   been supplied with an IP address of 192.168.1.10 for your use and have
  907.   been told that 192.168.1.1 is a router connected to the Internet.
  908.  
  909.   The first step is to configure the interface as described earlier. You
  910.   would use a command like:
  911.  
  912.        # ifconfig eth0 192.168.1.10 netmask 255.255.255.0 up
  913.  
  914.   You now need to add an entry into the routing table to tell the kernel
  915.   that datagrams for all hosts with addresses that match 192.168.1.*
  916.   should be sent to the ethernet device. You would use a command similar
  917.   to:
  918.  
  919.        # route add -net 192.168.1.0 netmask 255.255.255.0 eth0
  920.  
  921.   Note the use of the `-net' argument to tell the route program that
  922.   this entry is a network route. Your other choice here is a `-host'
  923.   route which is a route that is specific to one IP address.
  924.  
  925.   This route will enable you to establish IP connections with all of the
  926.   hosts on your ethernet segment. But what about all of the IP hosts
  927.   that aren't on your ethernet segment ?
  928.  
  929.   It would be a very difficult job to have to add routes to every
  930.   possible destination network, so there is a special trick that is used
  931.   to simplify this task. The trick is called the `default' route. The
  932.   default route matches every possible destination, but poorly, so that
  933.   if any other entry exists that matches the required address it will be
  934.   used instead of the default route. The idea of the default route is
  935.   simply to enable you to say "and everything else should go here". In
  936.   the example I've contrived you would use an entry like:
  937.  
  938.        # route add default gw 192.168.1.1 eth0
  939.  
  940.   The `gw' argument tells the route command that the next argument is
  941.   the IP address, or name, of a gateway or router machine which all
  942.   datagrams matching this entry should be directed to for further rout¡
  943.   ing.
  944.  
  945.   So, your complete configuration would look like:
  946.  
  947.        # ifconfig eth0 192.168.1.10 netmask 255.255.255.0 up
  948.        # route add -net 192.168.1.0 netmask 255.255.255.0 eth0
  949.        # route add default gw 192.168.1.1 eth0
  950.  
  951.   If you take a close look at your network `rc' files you will find that
  952.   at least one of them looks very similar to this. This is a very common
  953.   configuration.
  954.  
  955.   Let's now look at a slightly more complicated routing configuration.
  956.   Let's imagine we are configuring the router we looked at earlier, the
  957.   one supporting the PPP link to the Internet and the lan segments
  958.   feeding the workstations in the office. Lets imagine the router has
  959.   three ethernet segments and one PPP link. Our routing configuration
  960.   would look something like:
  961.  
  962.        # route add -net 192.168.1.0 netmask 255.255.255.0 eth0
  963.        # route add -net 192.168.2.0 netmask 255.255.255.0 eth1
  964.        # route add -net 192.168.3.0 netmask 255.255.255.0 eth2
  965.        # route add default ppp0
  966.  
  967.   Each of the workstations would use the simpler form presented above,
  968.   only the router needs to specify each of the network routes seperately
  969.   because for the workstations the default route mechanism will capture
  970.   all of them letting the router worry about splitting them up appropri¡
  971.   ately. You may be wondering why the default route presented doesn't
  972.   specify a `gw'.  The reason for this is simple, serial link protocols
  973.   such as PPP and slip only ever have two hosts on their network, one at
  974.   each end. To specify the host at the other end of the link as the
  975.   gateway is pointless and redundant as there is no other choice, so you
  976.   do not need to specify a gateway for these types of network connec¡
  977.   tions. Other network types such as ethernet, arcnet or token ring do
  978.   require the gateway to be specified as these networks support large
  979.   numbers of hosts on them.
  980.  
  981.   5.7.1.  So what does the routed program do ?
  982.  
  983.   The routing configuration described above is best suited to simple
  984.   network arrangements where there are only ever single possible paths
  985.   to destinations.  When you have a more complex network arrangement
  986.   things get a little more complicated. Fortunately for most of you this
  987.   won't be an issue.
  988.  
  989.   The big problem with `manual routing' or `static routing' as
  990.   described, is that if a machine or link fails in your network then the
  991.   only way you can direct your datagrams another way, if another way
  992.   exists, is by manually intervening and executing the appopriate
  993.   commands. Naturally this is clumsy, slow, impractical and hazard
  994.   prone. Various techniques have been developed to automatically adjust
  995.   routing tables in the event of network failures where there are
  996.   alternate routes, all of these techniques are loosely grouped by the
  997.   term `dynamic routing protocols'.
  998.  
  999.   You may have heard of some of the more common dynamic routing
  1000.   protocols. The most common are probably RIP (Routing Information
  1001.   Protocol) and OSPF (Open Shortest Path First Protocol). The Routing
  1002.   Information Protocol is very common on small networks such as small-
  1003.   medium sized corporate networks or building networks. OSPF is more
  1004.   modern and more capable at handling large network configurations and
  1005.   better suited to environments where there is a large number of
  1006.   possible paths through the network. Common implementations of these
  1007.   protocols are: `routed' - RIP and `gated' - RIP, OSPF and others.  The
  1008.   `routed' program is normally supplied with your Linux distribution or
  1009.   is included in the `NetKit' package detailed above.
  1010.  
  1011.   An example of where and how you might use a dynamic routing protocol
  1012.   might look something like the following:
  1013.  
  1014.       192.168.1.0 /                         192.168.2.0 /
  1015.          255.255.255.0                         255.255.255.0
  1016.        -                                     -
  1017.        |                                     |
  1018.        |   /-----\                 /-----\   |
  1019.        |   |     |ppp0   //    ppp0|     |   |
  1020.   eth0 |---|  A  |------//---------|  B  |---| eth0
  1021.        |   |     |     //          |     |   |
  1022.        |   \-----/                 \-----/   |
  1023.        |      \ ppp1             ppp1 /      |
  1024.        -       \                     /       -
  1025.                 \                   /
  1026.                  \                 /
  1027.                   \               /
  1028.                    \             /
  1029.                     \           /
  1030.                      \         /
  1031.                       \       /
  1032.                        \     /
  1033.                     ppp0\   /ppp1
  1034.                        /-----\
  1035.                        |     |
  1036.                        |  C  |
  1037.                        |     |
  1038.                        \-----/
  1039.                           |eth0
  1040.                           |
  1041.                      |---------|
  1042.                      192.168.3.0 /
  1043.                         255.255.255.0
  1044.  
  1045.   We have three routers A, B and C. Each supports one ethernet segment
  1046.   with a Class C IP network (netmask 255.255.255.0). Each router also
  1047.   has a PPP link to each of the other routers. The network forms a tri¡
  1048.   angle.
  1049.  
  1050.   It should be clear that the routing table at router A could look like:
  1051.  
  1052.        # route add -net 192.168.1.0 netmask 255.255.255.0 eth0
  1053.        # route add -net 192.168.2.0 netmask 255.255.255.0 ppp0
  1054.        # route add -net 192.168.3.0 netmask 255.255.255.0 ppp1
  1055.  
  1056.   This would work just fine until the link between router A and B should
  1057.   fail.  If that link failed then with the routing entry shown above
  1058.   hosts on the ethernet segment of A could not reach hosts on the ether¡
  1059.   net segment on B because their datagram would be directed to router
  1060.   A's ppp0 link which is broken. They could still continue to talk to
  1061.   hosts on the ethernet segment of C and hosts on the C's ethernet seg¡
  1062.   ment could still talk to hosts on B's ethernet segment because the
  1063.   link between B and C is still intact.
  1064.  
  1065.   But wait, if A can talk to C and C can still talk to B, why shouldn't
  1066.   A route its datagrams for B via C and let C send them to B ? This is
  1067.   exactly the sort of problem that dynamic routing protocols like RIP
  1068.   were designed to solve. If each of the routers A, B and C were running
  1069.   a routing daemon then their routing tables would be automatically
  1070.   adjusted to reflect the new state of the network should any one of the
  1071.   links in the network fail.  To configure such a network is simple, at
  1072.   each router you need only do two things. In this case for Router A:
  1073.        # route add -net 192.168.1.0 netmask 255.255.255.0 eth0
  1074.        # /usr/sbin/routed
  1075.  
  1076.   The `routed' routing daemon automatically finds all active network
  1077.   ports when it starts and sends and listens for messages on each of the
  1078.   network devices to allow it to determine and update the routing table
  1079.   on the host.
  1080.  
  1081.   This has been a very brief explanation of dynamic routing and where
  1082.   you would use it. If you want more information then you should refer
  1083.   to the suggested references listed at the top of the document.
  1084.  
  1085.   The important points relating to dynamic routing are:
  1086.  
  1087.   1. You only need to run a dynamic routing protocol daemon when your
  1088.      Linux machine has the possibility of selecting multiple possible
  1089.      routes to a destination.
  1090.  
  1091.   2. The dynamic routing daemon will automatically modify your routing
  1092.      table to adjust to changes in your network.
  1093.  
  1094.   3. RIP is suited to small to medium sized networks.
  1095.  
  1096.   5.8.  Configuring your network servers and services.
  1097.  
  1098.   Network servers and services are those programs that allow a remote
  1099.   user to make user of your Linux machine. Server programs listen on
  1100.   network ports.  Network ports are a means of addressing a particular
  1101.   service on any particular host and are how a server knows the
  1102.   difference between an incoming telnet connection and an incoming ftp
  1103.   connection. The remote user establishes a network connection to your
  1104.   machine and the server program, the network daemon program, listening
  1105.   on that port accepts the connection and executes. There are two ways
  1106.   that network daemons may operate. Both are commonly employed in
  1107.   practice. The two ways are:
  1108.  
  1109.      standalone
  1110.         the network daemon program listens on the designated network
  1111.         port and when an incoming connection is made it manages the
  1112.         network connection itself to provide the service.
  1113.  
  1114.      slave to the inetd server
  1115.         the inetd server is a special network daemon program that
  1116.         specialises in managing incoming network connections. It has a
  1117.         configuration file which tells it what program needs to be run
  1118.         when an incoming connection is received. Any service port may be
  1119.         configured for either of the tcp or udp protcols. The ports are
  1120.         described in another file that we will talk about soon.
  1121.  
  1122.   There are two important files that we need to configure. They are the
  1123.   /etc/services file which assigns names to port numbers and the
  1124.   /etc/inetd.conf file which is the configuration file for the inetd
  1125.   network daemon.
  1126.  
  1127.   5.8.1.  /etc/services
  1128.  
  1129.   The /etc/services file is a simple database that associates a human
  1130.   friendly name to a machine friendly service port. Its format is quite
  1131.   simple. The file is a text file with each line representing and entry
  1132.   in the database. Each entry is comprised of three fields seperated by
  1133.   any number of whitespace (tab or space) characters. The fields are:
  1134.   name      port/protocol        aliases     # comment
  1135.  
  1136.      name
  1137.         a single word name that represents the service being described.
  1138.  
  1139.      port/protocol
  1140.         this field is split into two subfields.
  1141.  
  1142.         port
  1143.            a number that specifies the port number the named service
  1144.            will be available on. Most of the common services have
  1145.            assigned service numbers. These are described in RFC-1340.
  1146.  
  1147.         protocol
  1148.            this subfield may be set to either tcp or udp.
  1149.  
  1150.         It is important to note that an entry of 18/tcp is very differ¡
  1151.         ent from an entry of 18/udp and that there is no technical rea¡
  1152.         son why the same service needs to exist on both. Normally common
  1153.         sense prevails and it is only if a particular service is avail¡
  1154.         able via both tcp and udp that you will see an entry for both.
  1155.  
  1156.      aliases
  1157.         other names that may be used to refer to this service entry.
  1158.  
  1159.   Any text appearing in a line after a `#' character is ignored and
  1160.   treated as a comment.
  1161.  
  1162.   5.8.1.1.  An example /etc/services file.
  1163.  
  1164.   All modern linux distributions provide a good /etc/services file.
  1165.   Just in case you happen to be building a machine from the ground up,
  1166.   here is a copy of the /etc/services file supplied with the Debian
  1167.   <http://www.debian.org/> distribution.
  1168.  
  1169.   # /etc/services:
  1170.   # $Id: services,v 1.3 1996/05/06 21:42:37 tobias Exp $
  1171.   #
  1172.   # Network services, Internet style
  1173.   #
  1174.   # Note that it is presently the policy of IANA to assign a single well-known
  1175.   # port number for both TCP and UDP; hence, most entries here have two entries
  1176.   # even if the protocol doesn't support UDP operations.
  1177.   # Updated from RFC 1340, ``Assigned Numbers'' (July 1992).  Not all ports
  1178.   # are included, only the more common ones.
  1179.  
  1180.   tcpmux          1/tcp                           # TCP port service multiplexer
  1181.   echo            7/tcp
  1182.   echo            7/udp
  1183.   discard         9/tcp           sink null
  1184.   discard         9/udp           sink null
  1185.   systat          11/tcp          users
  1186.   daytime         13/tcp
  1187.   daytime         13/udp
  1188.   netstat         15/tcp
  1189.   qotd            17/tcp          quote
  1190.   msp             18/tcp                          # message send protocol
  1191.   msp             18/udp                          # message send protocol
  1192.   chargen         19/tcp          ttytst source
  1193.   chargen         19/udp          ttytst source
  1194.   ftp-data        20/tcp
  1195.   ftp             21/tcp
  1196.   ssh             22/tcp                          # SSH Remote Login Protocol
  1197.   ssh             22/udp                          # SSH Remote Login Protocol
  1198.   telnet          23/tcp
  1199.   # 24 - private
  1200.   smtp            25/tcp          mail
  1201.   # 26 - unassigned
  1202.   time            37/tcp          timserver
  1203.   time            37/udp          timserver
  1204.   rlp             39/udp          resource        # resource location
  1205.   nameserver      42/tcp          name            # IEN 116
  1206.   whois           43/tcp          nicname
  1207.   re-mail-ck      50/tcp                          # Remote Mail Checking Protocol
  1208.   re-mail-ck      50/udp                          # Remote Mail Checking Protocol
  1209.   domain          53/tcp          nameserver      # name-domain server
  1210.   domain          53/udp          nameserver
  1211.   mtp             57/tcp                          # deprecated
  1212.   bootps          67/tcp                          # BOOTP server
  1213.   bootps          67/udp
  1214.   bootpc          68/tcp                          # BOOTP client
  1215.   bootpc          68/udp
  1216.   tftp            69/udp
  1217.   gopher          70/tcp                          # Internet Gopher
  1218.   gopher          70/udp
  1219.   rje             77/tcp          netrjs
  1220.   finger          79/tcp
  1221.   www             80/tcp          http            # WorldWideWeb HTTP
  1222.   www             80/udp                          # HyperText Transfer Protocol
  1223.   link            87/tcp          ttylink
  1224.   kerberos        88/tcp          kerberos5 krb5  # Kerberos v5
  1225.   kerberos        88/udp          kerberos5 krb5  # Kerberos v5
  1226.   supdup          95/tcp
  1227.   # 100 - reserved
  1228.   hostnames       101/tcp         hostname        # usually from sri-nic
  1229.   iso-tsap        102/tcp         tsap            # part of ISODE.
  1230.   csnet-ns        105/tcp         cso-ns          # also used by CSO name server
  1231.   csnet-ns        105/udp         cso-ns
  1232.   rtelnet         107/tcp                         # Remote Telnet
  1233.   rtelnet         107/udp
  1234.   pop-2           109/tcp         postoffice      # POP version 2
  1235.   pop-2           109/udp
  1236.   pop-3           110/tcp                         # POP version 3
  1237.   pop-3           110/udp
  1238.   sunrpc          111/tcp         portmapper      # RPC 4.0 portmapper TCP
  1239.   sunrpc          111/udp         portmapper      # RPC 4.0 portmapper UDP
  1240.   auth            113/tcp         authentication tap ident
  1241.   sftp            115/tcp
  1242.   uucp-path       117/tcp
  1243.   nntp            119/tcp         readnews untp   # USENET News Transfer Protocol
  1244.   ntp             123/tcp
  1245.   ntp             123/udp                         # Network Time Protocol
  1246.   netbios-ns      137/tcp                         # NETBIOS Name Service
  1247.   netbios-ns      137/udp
  1248.   netbios-dgm     138/tcp                         # NETBIOS Datagram Service
  1249.   netbios-dgm     138/udp
  1250.   netbios-ssn     139/tcp                         # NETBIOS session service
  1251.   netbios-ssn     139/udp
  1252.   imap2           143/tcp                         # Interim Mail Access Proto v2
  1253.   imap2           143/udp
  1254.   snmp            161/udp                         # Simple Net Mgmt Proto
  1255.   snmp-trap       162/udp         snmptrap        # Traps for SNMP
  1256.   cmip-man        163/tcp                         # ISO mgmt over IP (CMOT)
  1257.   cmip-man        163/udp
  1258.   cmip-agent      164/tcp
  1259.   cmip-agent      164/udp
  1260.   xdmcp           177/tcp                         # X Display Mgr. Control Proto
  1261.   xdmcp           177/udp
  1262.   nextstep        178/tcp         NeXTStep NextStep       # NeXTStep window
  1263.   nextstep        178/udp         NeXTStep NextStep       # server
  1264.   bgp             179/tcp                         # Border Gateway Proto.
  1265.   bgp             179/udp
  1266.   prospero        191/tcp                         # Cliff Neuman's Prospero
  1267.   prospero        191/udp
  1268.   irc             194/tcp                         # Internet Relay Chat
  1269.   irc             194/udp
  1270.   smux            199/tcp                         # SNMP Unix Multiplexer
  1271.   smux            199/udp
  1272.   at-rtmp         201/tcp                         # AppleTalk routing
  1273.   at-rtmp         201/udp
  1274.   at-nbp          202/tcp                         # AppleTalk name binding
  1275.   at-nbp          202/udp
  1276.   at-echo         204/tcp                         # AppleTalk echo
  1277.   at-echo         204/udp
  1278.   at-zis          206/tcp                         # AppleTalk zone information
  1279.   at-zis          206/udp
  1280.   z3950           210/tcp         wais            # NISO Z39.50 database
  1281.   z3950           210/udp         wais
  1282.   ipx             213/tcp                         # IPX
  1283.   ipx             213/udp
  1284.   imap3           220/tcp                         # Interactive Mail Access
  1285.   imap3           220/udp                         # Protocol v3
  1286.   ulistserv       372/tcp                         # UNIX Listserv
  1287.   ulistserv       372/udp
  1288.   #
  1289.   # UNIX specific services
  1290.   #
  1291.   exec            512/tcp
  1292.   biff            512/udp         comsat
  1293.   login           513/tcp
  1294.   who             513/udp         whod
  1295.   shell           514/tcp         cmd             # no passwords used
  1296.   syslog          514/udp
  1297.   printer         515/tcp         spooler         # line printer spooler
  1298.   talk            517/udp
  1299.   ntalk           518/udp
  1300.   route           520/udp         router routed   # RIP
  1301.   timed           525/udp         timeserver
  1302.   tempo           526/tcp         newdate
  1303.   courier         530/tcp         rpc
  1304.   conference      531/tcp         chat
  1305.   netnews         532/tcp         readnews
  1306.   netwall         533/udp                         # -for emergency broadcasts
  1307.   uucp            540/tcp         uucpd           # uucp daemon
  1308.   remotefs        556/tcp         rfs_server rfs  # Brunhoff remote filesystem
  1309.   klogin          543/tcp                         # Kerberized `rlogin' (v5)
  1310.   kshell          544/tcp         krcmd           # Kerberized `rsh' (v5)
  1311.   kerberos-adm    749/tcp                         # Kerberos `kadmin' (v5)
  1312.   #
  1313.   webster         765/tcp                         # Network dictionary
  1314.   webster         765/udp
  1315.   #
  1316.   # From ``Assigned Numbers'':
  1317.   #
  1318.   #> The Registered Ports are not controlled by the IANA and on most systems
  1319.   #> can be used by ordinary user processes or programs executed by ordinary
  1320.   #> users.
  1321.   #
  1322.   #> Ports are used in the TCP [45,106] to name the ends of logical
  1323.   #> connections which carry long term conversations.  For the purpose of
  1324.   #> providing services to unknown callers, a service contact port is
  1325.   #> defined.  This list specifies the port used by the server process as its
  1326.   #> contact port.  While the IANA can not control uses of these ports it
  1327.   #> does register or list uses of these ports as a convienence to the
  1328.   #> community.
  1329.   #
  1330.   ingreslock      1524/tcp
  1331.   ingreslock      1524/udp
  1332.   prospero-np     1525/tcp                # Prospero non-privileged
  1333.   prospero-np     1525/udp
  1334.   rfe             5002/tcp                # Radio Free Ethernet
  1335.   rfe             5002/udp                # Actually uses UDP only
  1336.   bbs             7000/tcp                # BBS service
  1337.   #
  1338.   #
  1339.   # Kerberos (Project Athena/MIT) services
  1340.   # Note that these are for Kerberos v4 and are unofficial.  Sites running
  1341.   # v4 should uncomment these and comment out the v5 entries above.
  1342.   #
  1343.   kerberos4       750/udp         kdc     # Kerberos (server) udp
  1344.   kerberos4       750/tcp         kdc     # Kerberos (server) tcp
  1345.   kerberos_master 751/udp                 # Kerberos authentication
  1346.   kerberos_master 751/tcp                 # Kerberos authentication
  1347.   passwd_server   752/udp                 # Kerberos passwd server
  1348.   krb_prop        754/tcp                 # Kerberos slave propagation
  1349.   krbupdate       760/tcp         kreg    # Kerberos registration
  1350.   kpasswd         761/tcp         kpwd    # Kerberos "passwd"
  1351.   kpop            1109/tcp                # Pop with Kerberos
  1352.   knetd           2053/tcp                # Kerberos de-multiplexor
  1353.   zephyr-srv      2102/udp                # Zephyr server
  1354.   zephyr-clt      2103/udp                # Zephyr serv-hm connection
  1355.   zephyr-hm       2104/udp                # Zephyr hostmanager
  1356.   eklogin         2105/tcp                # Kerberos encrypted rlogin
  1357.   #
  1358.   # Unofficial but necessary (for NetBSD) services
  1359.   #
  1360.   supfilesrv      871/tcp                 # SUP server
  1361.   supfiledbg      1127/tcp                # SUP debugging
  1362.   #
  1363.   # Datagram Delivery Protocol services
  1364.   #
  1365.   rtmp            1/ddp                   # Routing Table Maintenance Protocol
  1366.   nbp             2/ddp                   # Name Binding Protocol
  1367.   echo            4/ddp                   # AppleTalk Echo Protocol
  1368.   zip             6/ddp                   # Zone Information Protocol
  1369.   #
  1370.   # Debian GNU/Linux services
  1371.   rmtcfg          1236/tcp                # Gracilis Packeten remote config server
  1372.   xtel            1313/tcp                # french minitel
  1373.   cfinger         2003/tcp                # GNU Finger
  1374.   postgres        4321/tcp                # POSTGRES
  1375.   mandelspawn     9359/udp        mandelbrot      # network mandelbrot
  1376.  
  1377.   # Local services
  1378.  
  1379.   5.8.2.  /etc/inetd.conf
  1380.  
  1381.   The /etc/inetd.conf file is the configuration file for the inetd
  1382.   server daemon. Its function is to tell inetd what to do when it
  1383.   receives a connection request for a particular service. For each
  1384.   service that you wish to accept connections for you must tell inetd
  1385.   what network server daemon to run and how to run it.
  1386.  
  1387.   Its format is also fairly simple. It is a text file with each line
  1388.   describing a service that you wish to provide. Any text in a line
  1389.   following a `#' is ignored and considered a comment. Each line
  1390.   contains seven fields seperated by any number of whitespace (tab or
  1391.   space) characters. The general format is as follows:
  1392.  
  1393.        service  socket_type  proto  flags  user  server_path  server_args
  1394.  
  1395.      service
  1396.         is the service relevant to this configuration as taken from the
  1397.         /etc/services file.
  1398.  
  1399.      socket_type
  1400.         this field describes the type of socket that this entry will
  1401.         consider relevant, allowable values are: stream, dgram, raw,
  1402.         rdm, or seqpacket. This is a little technical in nature, but as
  1403.         a rule of thumb nearly all tcp based services use stream and
  1404.         nearly all udp based services use dgram. It is only very special
  1405.         types of server daemons that would use any of the other values.
  1406.  
  1407.      proto
  1408.         the protocol to considered valid for this entry. This should
  1409.         match the appropriate entry in the /etc/services file and will
  1410.         typically be either tcp or udp. Sun RPC (Remote Procedure Call)
  1411.         based servers will use rpc/tcp or rpc/udp.
  1412.  
  1413.      flags
  1414.         there are really only two possible settings for this field.
  1415.         This field setting tells inetd whether the network server
  1416.         program frees the socket after it has been started and therefore
  1417.         whether inetd can start another one on the next connection
  1418.         request, or whether inetd should wait and assume that any server
  1419.         daemon already running will handle the new connection request.
  1420.         Again this is a little tricky to work out, but as a rule of
  1421.         thumb all tcp servers should have this entry set to nowait and
  1422.         most udp servers should have this entry set to wait. Be warned
  1423.         there are some notable exceptions to this, so let the example
  1424.         guide you if you are not sure.
  1425.  
  1426.      user
  1427.         this field describes which user account from /etc/passwd will be
  1428.         set as the owner of the network daemon when it is started. This
  1429.         is often useful if you want to safeguard against security risks.
  1430.         You can set the user of an entry to the nobody user so that if
  1431.         the network server security is breached the possible damage is
  1432.         minimised.  Typically this field is set to root though, because
  1433.         many servers require root priveledges in order to function
  1434.         correctly.
  1435.  
  1436.      server_path
  1437.         this field is pathname to the actual server program to execute
  1438.         for this entry.
  1439.  
  1440.      server_args
  1441.         this field comprises the rest of the line and is optional. This
  1442.         field is where you place any command line arguments that you
  1443.         wish to pass to the server daemon program when it is launched.
  1444.  
  1445.   5.8.2.1.  An example /etc/inetd.conf
  1446.  
  1447.   As for the /etc/services file all modern distributions will include a
  1448.   good /etc/inetd.conf file for you to work with. Here, for completeness
  1449.   is the /etc/inetd.conf file from the Debian <http://www.debian.org/>
  1450.   distribution.
  1451.  
  1452.   # /etc/inetd.conf:  see inetd(8) for further informations.
  1453.   #
  1454.   # Internet server configuration database
  1455.   #
  1456.   #
  1457.   # Modified for Debian by Peter Tobias <tobias@et-inf.fho-emden.de>
  1458.   #
  1459.   # <service_name> <sock_type> <proto> <flags> <user> <server_path> <args>
  1460.   #
  1461.   # Internal services
  1462.   #
  1463.   #echo           stream  tcp     nowait  root    internal
  1464.   #echo           dgram   udp     wait    root    internal
  1465.   discard         stream  tcp     nowait  root    internal
  1466.   discard         dgram   udp     wait    root    internal
  1467.   daytime         stream  tcp     nowait  root    internal
  1468.   daytime         dgram   udp     wait    root    internal
  1469.   #chargen        stream  tcp     nowait  root    internal
  1470.   #chargen        dgram   udp     wait    root    internal
  1471.   time            stream  tcp     nowait  root    internal
  1472.   time            dgram   udp     wait    root    internal
  1473.   #
  1474.   # These are standard services.
  1475.   #
  1476.   telnet  stream  tcp     nowait  root    /usr/sbin/tcpd  /usr/sbin/in.telnetd
  1477.   ftp     stream  tcp     nowait  root    /usr/sbin/tcpd  /usr/sbin/in.ftpd
  1478.   #fsp    dgram   udp     wait    root    /usr/sbin/tcpd  /usr/sbin/in.fspd
  1479.   #
  1480.   # Shell, login, exec and talk are BSD protocols.
  1481.   #
  1482.   shell   stream  tcp     nowait  root    /usr/sbin/tcpd  /usr/sbin/in.rshd
  1483.   login   stream  tcp     nowait  root    /usr/sbin/tcpd  /usr/sbin/in.rlogind
  1484.   #exec   stream  tcp     nowait  root    /usr/sbin/tcpd  /usr/sbin/in.rexecd
  1485.   talk    dgram   udp     wait    root    /usr/sbin/tcpd  /usr/sbin/in.talkd
  1486.   ntalk   dgram   udp     wait    root    /usr/sbin/tcpd  /usr/sbin/in.ntalkd
  1487.   #
  1488.   # Mail, news and uucp services.
  1489.   #
  1490.   smtp    stream  tcp     nowait  root    /usr/sbin/tcpd  /usr/sbin/in.smtpd
  1491.   #nntp   stream  tcp     nowait  news    /usr/sbin/tcpd  /usr/sbin/in.nntpd
  1492.   #uucp   stream  tcp     nowait  uucp    /usr/sbin/tcpd  /usr/lib/uucp/uucico
  1493.   #comsat dgram   udp     wait    root    /usr/sbin/tcpd  /usr/sbin/in.comsat
  1494.   #
  1495.   # Pop et al
  1496.   #
  1497.   #pop-2  stream  tcp     nowait  root    /usr/sbin/tcpd  /usr/sbin/in.pop2d
  1498.   #pop-3  stream  tcp     nowait  root    /usr/sbin/tcpd  /usr/sbin/in.pop3d
  1499.   #
  1500.   # `cfinger' is for the GNU finger server available for Debian.  (NOTE: The
  1501.   # current implementation of the `finger' daemon allows it to be run as `root'.)
  1502.   #
  1503.   #cfinger stream tcp     nowait  root    /usr/sbin/tcpd  /usr/sbin/in.cfingerd
  1504.   #finger stream  tcp     nowait  root    /usr/sbin/tcpd  /usr/sbin/in.fingerd
  1505.   #netstat        stream  tcp     nowait  nobody  /usr/sbin/tcpd  /bin/netstat
  1506.   #systat stream  tcp     nowait  nobody  /usr/sbin/tcpd  /bin/ps -auwwx
  1507.   #
  1508.   # Tftp service is provided primarily for booting.  Most sites
  1509.   # run this only on machines acting as "boot servers."
  1510.   #
  1511.   #tftp   dgram   udp     wait    nobody  /usr/sbin/tcpd  /usr/sbin/in.tftpd
  1512.   #tftp   dgram   udp     wait    nobody  /usr/sbin/tcpd  /usr/sbin/in.tftpd /boot
  1513.   #bootps dgram   udp     wait    root    /usr/sbin/bootpd        bootpd -i -t 120
  1514.   #
  1515.   # Kerberos authenticated services (these probably need to be corrected)
  1516.   #
  1517.   #klogin         stream  tcp     nowait  root    /usr/sbin/tcpd  /usr/sbin/in.rlogind -k
  1518.   #eklogin        stream  tcp     nowait  root    /usr/sbin/tcpd  /usr/sbin/in.rlogind -k -x
  1519.   #kshell         stream  tcp     nowait  root    /usr/sbin/tcpd  /usr/sbin/in.rshd -k
  1520.   #
  1521.   # Services run ONLY on the Kerberos server (these probably need to be corrected)
  1522.   #
  1523.   #krbupdate      stream tcp      nowait  root    /usr/sbin/tcpd  /usr/sbin/registerd
  1524.   #kpasswd        stream  tcp     nowait  root    /usr/sbin/tcpd  /usr/sbin/kpasswdd
  1525.   #
  1526.   # RPC based services
  1527.   #
  1528.   #mountd/1       dgram   rpc/udp wait    root    /usr/sbin/tcpd  /usr/sbin/rpc.mountd
  1529.   #rstatd/1-3     dgram   rpc/udp wait    root    /usr/sbin/tcpd  /usr/sbin/rpc.rstatd
  1530.   #rusersd/2-3    dgram   rpc/udp wait    root    /usr/sbin/tcpd  /usr/sbin/rpc.rusersd
  1531.   #walld/1        dgram   rpc/udp wait    root    /usr/sbin/tcpd  /usr/sbin/rpc.rwalld
  1532.   #
  1533.   # End of inetd.conf.
  1534.   ident           stream  tcp     nowait  nobody  /usr/sbin/identd        identd -i
  1535.  
  1536.   5.9.  Other miscellaneous network related configuration files.
  1537.  
  1538.   There are a number of miscellaneous files relating to network
  1539.   configuration under linux that you might be interested in. You may
  1540.   never have to modify these files, but it is worth describing them so
  1541.   you know what they contain and what they are for.
  1542.  
  1543.   5.9.1.  /etc/protocols
  1544.  
  1545.   The /etc/protocols file is a database that maps protocol id numbers
  1546.   against protocol names. This is used by programmers to allow them to
  1547.   specify protocols by name in their programs and also by some programs
  1548.   such as tcpdump to allow them to display names instead of numbers in
  1549.   their output. The general syntax of the file is:
  1550.  
  1551.        protocolname  number  aliases
  1552.  
  1553.   The /etc/protocols file supplied with the Debian
  1554.   <http://www.debian.org/> distribution is as follows:
  1555.  
  1556.   # /etc/protocols:
  1557.   # $Id: protocols,v 1.1 1995/02/24 01:09:41 imurdock Exp $
  1558.   #
  1559.   # Internet (IP) protocols
  1560.   #
  1561.   #       from: @(#)protocols     5.1 (Berkeley) 4/17/89
  1562.   #
  1563.   # Updated for NetBSD based on RFC 1340, Assigned Numbers (July 1992).
  1564.  
  1565.   ip      0       IP              # internet protocol, pseudo protocol number
  1566.   icmp    1       ICMP            # internet control message protocol
  1567.   igmp    2       IGMP            # Internet Group Management
  1568.   ggp     3       GGP             # gateway-gateway protocol
  1569.   ipencap 4       IP-ENCAP        # IP encapsulated in IP (officially ``IP'')
  1570.   st      5       ST              # ST datagram mode
  1571.   tcp     6       TCP             # transmission control protocol
  1572.   egp     8       EGP             # exterior gateway protocol
  1573.   pup     12      PUP             # PARC universal packet protocol
  1574.   udp     17      UDP             # user datagram protocol
  1575.   hmp     20      HMP             # host monitoring protocol
  1576.   xns-idp 22      XNS-IDP         # Xerox NS IDP
  1577.   rdp     27      RDP             # "reliable datagram" protocol
  1578.   iso-tp4 29      ISO-TP4         # ISO Transport Protocol class 4
  1579.   xtp     36      XTP             # Xpress Tranfer Protocol
  1580.   ddp     37      DDP             # Datagram Delivery Protocol
  1581.   idpr-cmtp       39      IDPR-CMTP       # IDPR Control Message Transport
  1582.   rspf    73      RSPF            # Radio Shortest Path First.
  1583.   vmtp    81      VMTP            # Versatile Message Transport
  1584.   ospf    89      OSPFIGP         # Open Shortest Path First IGP
  1585.   ipip    94      IPIP            # Yet Another IP encapsulation
  1586.   encap   98      ENCAP           # Yet Another IP encapsulation
  1587.  
  1588.   5.9.2.  /etc/networks
  1589.  
  1590.   The /etc/networks file has a similar function to that of the
  1591.   /etc/hosts file. It provides a simple database of network names
  1592.   against network addresses. Its format differs in that there may be
  1593.   only two fields per line and that the fields are coded as:
  1594.  
  1595.        networkname networkaddress
  1596.  
  1597.   An example might look like:
  1598.  
  1599.        loopnet    127.0.0.0
  1600.        localnet   192.168.0.0
  1601.        amprnet    44.0.0.0
  1602.  
  1603.   When you use commands like the route command, if a destination is a
  1604.   network and that network has an entry in the /etc/networks file then
  1605.   the route command will display that network name instead of its
  1606.   address.
  1607.  
  1608.   5.10.  Network Security and access control.
  1609.  
  1610.   Let me start this section by warning you that securing your machine
  1611.   and network against malicious attack is a complex art. I do not
  1612.   consider myself an expert in this field at all and while the following
  1613.   mechanisms I describe will help, if you are serious about security
  1614.   then I recommend you do some research of your own into the subject.
  1615.   There are many good references on the Internet relating to the
  1616.   subject.
  1617.  
  1618.   An important rule of thumb is: `Don't run servers you don't intend to
  1619.   use'.  Many distributions come configured with all sorts of services
  1620.   configured and automatically started. To ensure even a minimum level
  1621.   of safety you should go through your /etc/inetd.conf file and comment
  1622.   out (place a `#' at the start of the line) any entries for services
  1623.   you don't intend to use.  Good candidates are services such as: shell,
  1624.   login, exec, uucp, ftp and informational services such as finger,
  1625.   netstat and systat.
  1626.  
  1627.   There are all sorts of security and access control mechanisms, I'll
  1628.   describe the most elementary of them.
  1629.  
  1630.   5.10.1.  /etc/ftpusers
  1631.  
  1632.   The /etc/ftpusers file is a simple mechanism that allows you to deny
  1633.   certain users from logging into your machine via ftp. The
  1634.   /etc/ftpusers file is read by the ftp daemon program (ftpd) when an
  1635.   incoming ftp connection is received. The file is a simple list of
  1636.   those users who are disallowed from logging in. It might looks
  1637.   something like:
  1638.  
  1639.        # /etc/ftpusers - users not allowed to login via ftp
  1640.        root
  1641.        uucp
  1642.        bin
  1643.        mail
  1644.  
  1645.   5.10.2.  /etc/securetty
  1646.  
  1647.   The /etc/securetty file allows you to specify which tty devices root
  1648.   is allowed to login on. The /etc/securetty file is read by the login
  1649.   program (usually /bin/login). Its format is a list of the tty devices
  1650.   names allowed, on all others root login is disallowed:
  1651.  
  1652.        # /etc/securetty - tty's on which root is allowed to login
  1653.        tty1
  1654.        tty2
  1655.        tty3
  1656.        tty4
  1657.  
  1658.   5.10.3.  The tcpd hosts access control mechanism.
  1659.  
  1660.   The tcpd program you will have seen listed in the same /etc/inetd.conf
  1661.   provides logging and access control mechanisms to services it is
  1662.   configured to protect.
  1663.   When it is invoked by the inetd program it reads two files containing
  1664.   access rules and either allows or denies access to the server it is
  1665.   protecting accordingly.
  1666.  
  1667.   It will search the rules files until the first match is found. If no
  1668.   match is found then it assumes that access should be allowed to
  1669.   anyone. The files it searches in sequence are: /etc/hosts.allow,
  1670.   /etc/hosts.deny.  I'll describe each of these in turn. For a complete
  1671.   description of this facility you should refer to the appopriate man
  1672.   pages (hosts_access(5) is a good starting point).
  1673.  
  1674.   5.10.3.1.  /etc/hosts.allow
  1675.  
  1676.   The /etc/hosts.allow file is a configuration file of the
  1677.   /usr/sbin/tcpd program. The hosts.allow file contains rules describing
  1678.   which hosts are allowed access to a service on your machine.
  1679.  
  1680.   The file format is quite simple:
  1681.  
  1682.        # /etc/hosts.allow
  1683.        #
  1684.        # <service list>: <host list> [: command]
  1685.  
  1686.      service list
  1687.         is a comma delimited list of server names that this rule applies
  1688.         to.  Example server names are: ftpd, telnetd and fingerd.
  1689.  
  1690.      host list
  1691.         is a comma delimited list of host names. You may also use IP
  1692.         addresses here. You may additionally specify hostnames or
  1693.         addresses using wildcard characters to match groups of hosts.
  1694.         Examples include: gw.vk2ktj.ampr.org to match a specific host,
  1695.         .uts.edu.au to match any hostname ending in that string, 44. to
  1696.         match any IP address commencing with those digits.  There are
  1697.         some special tokens to simplify configuration, some of these
  1698.         are: ALL matches every host, LOCAL matches any host whose name
  1699.         does not contain a `.' ie is in the same domain as your machine
  1700.         and PARANOID matches any host whose name does not match its
  1701.         address (name spoofing). There is one last token that is also
  1702.         useful. The EXCEPT token allows you to provide a list with
  1703.         exceptions. This will be covered in an example later.
  1704.  
  1705.      command
  1706.         is an optional parameter. This parameter is the full pathname of
  1707.         a command that would be executed everytime this rule is matched.
  1708.         It could for example run a command that would attempt to
  1709.         identify who is logged onto the connecting host, or to generate
  1710.         a mail message or some other warning to a system administrator
  1711.         that someone is attempting to connect. There are a number of
  1712.         expansions that may be included, some common examples are: %h
  1713.         expands to the name of the connecting host or address if it
  1714.         doesn't have a name, %d the daemon name being called.
  1715.  
  1716.   An example:
  1717.  
  1718.   # /etc/hosts.allow
  1719.   #
  1720.   # Allow mail to anyone
  1721.   in.smtpd: ALL
  1722.   # All telnet and ftp to only hosts within my domain and my host at home.
  1723.   telnetd, ftpd: LOCAL, myhost.athome.org.au
  1724.   # Allow finger to anyone but keep a record of who they are.
  1725.   fingerd: ALL: (finger @%h | mail -s "finger from %h" root)
  1726.  
  1727.   5.10.3.2.  /etc/hosts.deny
  1728.  
  1729.   The /etc/hosts.deny file is a configuration file of the /usr/sbin/tcpd
  1730.   program. The hosts.deny file contains rules describing which hosts are
  1731.   disallowed access to a service on your machine.
  1732.  
  1733.   A simple sample would look something like this:
  1734.  
  1735.        # /etc/hosts.deny
  1736.        #
  1737.        # Disallow all hosts with suspect hostnames
  1738.        ALL: PARANOID
  1739.        #
  1740.        # Disallow all hosts.
  1741.        ALL: ALL
  1742.  
  1743.   The PARANOID entry is really redundant because the other entry traps
  1744.   everything in any case. Either of these entry would make a reasonable
  1745.   default depending on your particular requirement.
  1746.  
  1747.   Having an ALL: ALL default in the /etc/hosts.deny and then
  1748.   specifically enabling on those services and hosts that you want in the
  1749.   /etc/hosts.allow file is the safest configuration.
  1750.  
  1751.   5.10.4.  /etc/hosts.equiv
  1752.  
  1753.   The hosts.equiv file is used to grant certain hosts and users access
  1754.   rights to accounts on your machine without having to supply a
  1755.   password. This is useful in a secure environment where you control all
  1756.   machines, but is a security hazard otherwise. Your machine is only as
  1757.   secure as the least secure of the trusted hosts. To maximise security,
  1758.   don't use this mechanism and encourage your users not to use the
  1759.   .rhosts file as well.
  1760.  
  1761.   5.10.5.  Configure your ftp daemon properly.
  1762.  
  1763.   Many sites will be interested in running an anonymous ftp server to
  1764.   allow other people to upload and download files without requiring a
  1765.   specific userid. If you decide to offer this facility make sure you
  1766.   configure the ftp daemon properly for anonymous access. Most man pages
  1767.   for ftpd(8) describe in some length how to go about this. You should
  1768.   always ensure that you follow these instructions. An important tip is
  1769.   to not use a copy of your /etc/passwd file in the anonymous account
  1770.   /etc directory, make sure you strip out all account details except
  1771.   those that you must have, otherwise you will be vulnerable to brute
  1772.   force password cracking techniques.
  1773.   5.10.6.  Network Firewalling.
  1774.  
  1775.   Not allowing datagrams to even reach your machine or servers is an
  1776.   excellent means of security. This is covered in depth in the Firewall-
  1777.   HOWTO <Firewall-HOWTO.html>.
  1778.  
  1779.   5.10.7.  Other suggestions.
  1780.  
  1781.   Here are some other, potentially religious suggestions for you to
  1782.   consider.
  1783.  
  1784.      sendmail
  1785.         despite its popularity the sendmail daemon appears with
  1786.         frightening regularity on security warning announcements. Its up
  1787.         to you, but I choose not to run it.
  1788.  
  1789.      NFS and other Sun RPC services
  1790.         be wary of these. There are all sorts of possible exploits for
  1791.         these services. It is difficult finding an option to services
  1792.         like NFS, but if you configure them, make sure you are careful
  1793.         with who you allow mount rights to.
  1794.  
  1795.   6.  Network Technology Specific Information.
  1796.  
  1797.   The following subsections are specific to particular network
  1798.   technologies.  The information contained in these sections does not
  1799.   necessarily apply to any other type of network technology.
  1800.  
  1801.   6.1.  ARCNet
  1802.  
  1803.   ARCNet device names are `arc0e', `arc1e', `arc2e' etc. or `arc0s',
  1804.   `arc1s', `arc2s' etc. The first card detected by the kernel is
  1805.   assigned `arc0e' or `arc0s' and the rest are assigned sequentially in
  1806.   the order they are detected. The letter at the end signifies whether
  1807.   you've selected ethernet encapsulation packet format or RFC1051 packet
  1808.   format.
  1809.  
  1810.   Kernel Compile Options:
  1811.  
  1812.        Network device support  --->
  1813.            [*] Network device support
  1814.            <*> ARCnet support
  1815.            [ ]   Enable arc0e (ARCnet "Ether-Encap" packet format)
  1816.            [ ]   Enable arc0s (ARCnet RFC1051 packet format)
  1817.  
  1818.   Once you have your kernel properly built to support your ethernet card
  1819.   then configuration of the card is easy.
  1820.  
  1821.   Typically you would use something like:
  1822.  
  1823.        # ifconfig arc0e 192.168.0.1 netmask 255.255.255.0 up
  1824.        # route add -net 192.168.0.0 netmask 255.255.255.0 arc0e
  1825.  
  1826.   Please refer to the /usr/src/linux/Documentation/networking/arcnet.txt
  1827.   and /usr/src/linux/Documentation/networking/arcnet-hardware.txt files
  1828.   for further information.
  1829.  
  1830.   ARCNet support was developed by Avery Pennarun, apenwarr@foxnet.net.
  1831.  
  1832.   6.2.  Appletalk (AF_APPLETALK)
  1833.  
  1834.   The Appletalk support has no special device names as it uses existing
  1835.   network devices.
  1836.  
  1837.   Kernel Compile Options:
  1838.  
  1839.        Networking options  --->
  1840.            <*> Appletalk DDP
  1841.  
  1842.   Appletalk support allows your Linux machine to interwork with Apple
  1843.   networks.  An important use for this is to share resources such as
  1844.   printers and disks between both your Linux and Apple computers. Addi¡
  1845.   tional software is required, this is called netatalk. Wesley Craig
  1846.   netatalk@umich.edu represents a team called the `Research Systems Unix
  1847.   Group' at the University of Michigan and they have produced the
  1848.   netatalk package which provides software that implements the Appletalk
  1849.   protocol stack and some useful utilities.  The netatalk package will
  1850.   either have been supplied with your Linux distribution, or you will
  1851.   have to ftp it from its home site at the University of Michigan
  1852.   <ftp://terminator.rs.itd.umich.edu/unix/netatalk/>
  1853.  
  1854.   To build and install the package do something like:
  1855.  
  1856.        # cd /usr/src
  1857.        # tar xvfz .../netatalk-1.4b2.tar.Z
  1858.        - You may want to edit the `Makefile' at this point, specifically to change
  1859.          the DESTDIR variable which defines where the files will be installed later.
  1860.          The default of /usr/local/atalk is fairly safe.
  1861.        # make
  1862.        - as root:
  1863.        # make install
  1864.  
  1865.   6.2.1.  Configuring the Appletalk software.
  1866.  
  1867.   The first thing you need to do to make it all work is to ensure that
  1868.   the appropriate entries in the /etc/services file are present. The
  1869.   entries you need are:
  1870.  
  1871.        rtmp    1/ddp   # Routing Table Maintenance Protocol
  1872.        nbp     2/ddp   # Name Binding Protocol
  1873.        echo    4/ddp   # AppleTalk Echo Protocol
  1874.        zip     6/ddp   # Zone Information Protocol
  1875.  
  1876.   The next step is to create the Appletalk configuration files in the
  1877.   /usr/local/atalk/etc directory (or wherever you installed the
  1878.   package).
  1879.  
  1880.   The first file to create is the /usr/local/atalk/etc/atalkd.conf file.
  1881.   Initially this file needs only one line that gives the name of the
  1882.   network device that supports the network that your Apple machines are
  1883.   on:
  1884.  
  1885.        eth0
  1886.  
  1887.   The Appletalk daemon program will add extra details after it is run.
  1888.  
  1889.   6.2.2.  Exporting a Linux filesystems via Appletalk.
  1890.  
  1891.   You can export filesystems from your linux machine to the network so
  1892.   that Apple machine on the network can share them.
  1893.  
  1894.   To do this you must configure the
  1895.   /usr/local/atalk/etc/AppleVolumes.system file. There is another
  1896.   configuration file called /usr/local/atalk/etc/AppleVolumes.default
  1897.   which has exactly the same format and describes which filesystems
  1898.   users connecting with guest priveledges will receive.
  1899.  
  1900.   Full details on how to configure these files and what the various
  1901.   options are can be found in the afpd man page.
  1902.  
  1903.   A simple example might look like:
  1904.  
  1905.        /tmp Scratch
  1906.        /home/ftp/pub "Public Area"
  1907.  
  1908.   Which would export your /tmp filesystem as AppleShare Volume `Scratch'
  1909.   and your ftp public directory as AppleShare Volume `Public Area'.  The
  1910.   volume names are not mandatory, the daemon will choose some for you,
  1911.   but it won't hurt to specify them anyway.
  1912.  
  1913.   6.2.3.  Sharing your Linux printer across Appletalk.
  1914.  
  1915.   You can share your linux printer with your Apple machines quite
  1916.   simply.  You need to run the papd program which is the Appletalk
  1917.   Printer Access Protocol Daemon. When you run this program it will
  1918.   accept requests from your Apple machines and spool the print job to
  1919.   your local line printer daemon for printing.
  1920.  
  1921.   You need to edit the /usr/local/atalk/etc/papd.conf file to configure
  1922.   the daemon. The syntax of this file is the same as that of your usual
  1923.   /etc/printcap file. The name you give to the definition is registered
  1924.   with the Appletalk naming protocol, NBP.
  1925.  
  1926.   A sample configuration might look like:
  1927.  
  1928.        TricWriter:\
  1929.           :pr=lp:op=cg:
  1930.  
  1931.   Which would make a printer named `TricWriter' available to your
  1932.   Appletalk network and all accepted jobs would be printed to the linux
  1933.   printer `lp' (as defined in the /etc/printcap file) using lpd. The
  1934.   entry `op=cg' says that the linux user `cg' is the operator of the
  1935.   printer.
  1936.  
  1937.   6.2.4.  Starting the appletalk software.
  1938.  
  1939.   Ok, you should now be ready to test this basic configuration. There is
  1940.   an rc.atalk file supplied with the netatalk package that should work
  1941.   ok for you, so all you should have to do is:
  1942.  
  1943.        # /usr/local/atalk/etc/rc.atalk
  1944.  
  1945.   and all should startup and run ok. You should see no error messages
  1946.   and the software will send messages to the console indicating each
  1947.   stage as it starts.
  1948.  
  1949.   6.2.5.  Testing the appletalk software.
  1950.  
  1951.   To test that the software is functioning properly, go to one of your
  1952.   Apple machines, pull down the Apple menu, select the Chooser, click on
  1953.   AppleShare, and your Linux box should appear.
  1954.  
  1955.   6.2.6.  Caveats of the appletalk software.
  1956.  
  1957.   ╖  You may need to start the Appletalk support before you configure
  1958.      your IP network. If you have problems starting the Appletalk
  1959.      programs, or if after you start them you have trouble with your IP
  1960.      network, then try starting the Appletalk software before you run
  1961.      your /etc/rc.d/rc.inet1 file.
  1962.  
  1963.   ╖  The afpd (Apple Filing Protocol Daemon) severely messes up your
  1964.      hard disk. Below the mount points it creates a couple of
  1965.      directories called .AppleDesktop and Network Trash Folder. Then,
  1966.      for each directory you access it will create a .AppleDouble below
  1967.      it so it can store resource forks, etc. So think twice before
  1968.      exporting /, you will have a great time cleaning up afterwards.
  1969.  
  1970.   ╖  The afpd program expects clear text passwords from the Macs.
  1971.      Security could be a problem, so be very careful when you run this
  1972.      daemon on a machine connected to the Internet, you have yourself to
  1973.      blame if somebody nasty does something bad.
  1974.  
  1975.   ╖  The existing diagnostic tools such as netstat and ifconfig don't
  1976.      support Appletalk. The raw information is available in the
  1977.      /proc/net/ directory if you need it.
  1978.  
  1979.   6.2.7.  More information
  1980.  
  1981.   For a much more detailed description of how to configure Appletalk for
  1982.   Linux refer to Anders Brownworth Linux Netatalk-HOWTO page at
  1983.   thehamptons.com <http://thehamptons.com/anders/netatalk/>.
  1984.  
  1985.   6.3.  ATM
  1986.  
  1987.   Werner Almesberger <werner.almesberger@lrc.di.epfl.ch> is managing a
  1988.   project to provide Asynchronous Transfer Mode support for Linux.
  1989.   Current information on the status of the project may be obtained from:
  1990.   lrcwww.epfl.ch <http://lrcwww.epfl.ch/linux-atm/>.
  1991.  
  1992.   6.4.  AX25 (AF_AX25)
  1993.  
  1994.   AX.25 device names are `sl0', `sl1', etc. in 2.0.* kernels or `ax0',
  1995.   `ax1', etc. in 2.1.* kernels.
  1996.  
  1997.   Kernel Compile Options:
  1998.  
  1999.        Networking options  --->
  2000.            [*] Amateur Radio AX.25 Level 2
  2001.  
  2002.   The AX25, Netrom and Rose protocols are covered by the AX25-HOWTO
  2003.   <AX25-HOWTO.html>.  These protocols are used by Amateur Radio Opera¡
  2004.   tors world wide in packet radio experimentation.
  2005.  
  2006.   Most of the work for implementation of these protocols has been done
  2007.   by Jonathon Naylor, jsn@cs.nott.ac.uk.
  2008.  
  2009.   6.5.  DECNet
  2010.  
  2011.   Support for DECNet is currently being worked on. You should expect it
  2012.   to appear in a late 2.1.* kernel.
  2013.  
  2014.   6.6.  EQL - multiple line traffic equaliser
  2015.  
  2016.   The EQL device name is `eql'. With the standard kernel source you may
  2017.   have only one EQL device per machine. EQL provides a means of
  2018.   utilising multiple point to point lines such as PPP, slip or plip as a
  2019.   single logical link to carry tcp/ip. Often it is cheaper to use
  2020.   multiple lower speed lines than to have one high speed line installed.
  2021.  
  2022.   Kernel Compile Options:
  2023.  
  2024.        Network device support  --->
  2025.            [*] Network device support
  2026.            <*> EQL (serial line load balancing) support
  2027.  
  2028.   To support this mechanism the machine at the other end of the lines
  2029.   must also support EQL. Linux, Livingstone Portmasters and newer dial-
  2030.   in servers support compatible facilities.
  2031.  
  2032.   To configure EQL you will need the eql tools which are available from:
  2033.   sunsite.unc.edu
  2034.   <ftp://sunsite.unc.edu/pub/linux/system/Serial/eql-1.2.tar.gz>.
  2035.  
  2036.   Configuration is fairly straightforward. You start by configuring the
  2037.   eql interface. The eql interface is just like any other network
  2038.   device. You configure the IP address and mtu using the ifconfig
  2039.   utility, so something like:
  2040.        ifconfig eql 192.168.10.1 mtu 1006
  2041.  
  2042.   Next you need to manually initiate each of the lines you will use.
  2043.   These may be any combination of point to point network devices. How
  2044.   you initiate the connections will depend on what sort of link they
  2045.   are, refer to the appropriate sections for further information.
  2046.  
  2047.   Lastly you need to associate the serial link with the EQL device, this
  2048.   is called `enslaving' and is done with the eql_enslave command as
  2049.   shown:
  2050.  
  2051.        eql_enslave eql sl0 28800
  2052.        eql_enslave eql ppp0 14400
  2053.  
  2054.   The `estimated speed' parameter you supply eql_enslave doesn't do any¡
  2055.   thing directly. It is used by the EQL driver to determine what share
  2056.   of the datagrams that device should receive, so you can fine tune the
  2057.   balancing of the lines by playing with this value.
  2058.  
  2059.   To disassociate a line from an EQL device you use the eql_emancipate
  2060.   command as shown:
  2061.  
  2062.        eql_emancipate eql sl0
  2063.  
  2064.   You add routing as you would for any other point to point link, except
  2065.   your routes should refer to the eql device rather than the actual
  2066.   serial devices themselves, typically you would use:
  2067.  
  2068.        route add default eql
  2069.  
  2070.   The EQL driver was developed by Simon Janes, simon@ncm.com.
  2071.  
  2072.   6.7.  Ethernet
  2073.  
  2074.   Ethernet device names are `eth0', `eth1', `eth2' etc. The first card
  2075.   detected by the kernel is assigned `eth0' and the rest are assigned
  2076.   sequentially in the order they are detected.
  2077.  
  2078.   To learn how to make your ethernet card working under Linux you should
  2079.   refer to the Ethernet-HOWTO <Ethernet-HOWTO.html>.
  2080.  
  2081.   Once you have your kernel properly built to support your ethernet card
  2082.   then configuration of the card is easy.
  2083.  
  2084.   Typically you would use something like:
  2085.  
  2086.        # ifconfig eth0 192.168.0.1 netmask 255.255.255.0 up
  2087.        # route add -net 192.168.0.0 netmask 255.255.255.0 eth0
  2088.  
  2089.   Most of the ethernet drivers were developed by Donald Becker,
  2090.   becker@CESDIS.gsfc.nasa.gov.
  2091.  
  2092.   6.8.  FDDI
  2093.  
  2094.   FDDI device names are `fddi0', `fddi1', `fddi2' etc. The first card
  2095.   detected by the kernel is assigned `fddi0' and the rest are assigned
  2096.   sequentially in the order they are detected.
  2097.  
  2098.   Lawrence V. Stefani, larry_stefani@us.newbridge.com, has developed a
  2099.   driver for the Digital Equipment Corporation FDDI EISA and PCI cards.
  2100.  
  2101.   Kernel Compile Options:
  2102.  
  2103.        Network device support  --->
  2104.            [*] FDDI driver support
  2105.            [*] Digital DEFEA and DEFPA adapter support
  2106.  
  2107.   When you have your kernel built to support the FDDI driver and
  2108.   installed, configuration of the FDDI interface is almost identical
  2109.   that for an ethernet interface. You just specify the appropraite FDDI
  2110.   interface name in the ifconfig and route comands.
  2111.  
  2112.   6.9.  Frame Relay
  2113.  
  2114.   The Frame Relay device names are `dlci00', `dlci01' etc for the DLCI
  2115.   encapsulation devices and `sdla0', `sdla1' etc for the FRAD(s).
  2116.  
  2117.   Frame Relay is a new networking technology that is designed to suit
  2118.   data communications traffic that is of a `bursty' or intermittent
  2119.   nature. You connect to a Frame Relay network using a Frame Relay
  2120.   Access Device (FRAD).  The Linux Frame Relay supports IP over Frame
  2121.   Relay as described in RFC-1490.
  2122.  
  2123.   Kernel Compile Options:
  2124.  
  2125.        Network device support  --->
  2126.            <*> Frame relay DLCI support (EXPERIMENTAL)
  2127.            (24)   Max open DLCI
  2128.            (8)   Max DLCI per device
  2129.            <*>   SDLA (Sangoma S502/S508) support
  2130.  
  2131.   Mike McLagan, mike.mclagan@linux.org, developed the Frame Relay
  2132.   support and configuration tools.
  2133.  
  2134.   Currently the only FRAD supported are the Sangoma Technologies
  2135.   <http://www.sangoma.com/> S502A, S502E and S508.
  2136.  
  2137.   To configure the FRAD and DLCI devices after you have rebuilt your
  2138.   kernel you will need the Frame Relay configuration tools. These are
  2139.   available from ftp.invlogic.com
  2140.   <ftp://ftp.invlogic.com/pub/linux/fr/frad-0.15.tgz>.  Compiling and
  2141.   installing the tools is straightforward, but the lack of a top level
  2142.   Makefile makes it a fairly manual process:
  2143.  
  2144.   # cd /usr/src
  2145.   # tar xvfz .../frad-0.15.tgz
  2146.   # cd frad-0.15
  2147.   # for i in common dlci frad; make -C $i clean; make -C $i; done
  2148.   # mkdir /etc/frad
  2149.   # install -m 644 -o root -g root bin/*.sfm /etc/frad
  2150.   # install -m 700 -o root -g root frad/fradcfg /sbin
  2151.   # install -m 700 -o root -g root dlci/dlcicfg /sbin
  2152.  
  2153.   After installing the tools you need to create an /etc/frad/router.conf
  2154.   file. You can use this template, which is a modified version of one of
  2155.   the example files:
  2156.  
  2157.   # /etc/frad/router.conf
  2158.   # This is a template configuration for frame relay.
  2159.   # All tags are included. The default values are based on the code
  2160.   # supplied with the DOS drivers for the Sangoma S502A card.
  2161.   #
  2162.   # A '#' anywhere in a line constitutes a comment
  2163.   # Blanks are ignored (you can indent with tabs too)
  2164.   # Unknown [] entries and unknown keys are ignored
  2165.   #
  2166.  
  2167.   [Devices]
  2168.   Count=1                 # number of devices to configure
  2169.   Dev_1=sdla0             # the name of a device
  2170.   #Dev_2=sdla1            # the name of a device
  2171.  
  2172.   # Specified here, these are applied to all devices and can be overriden for
  2173.   # each individual board.
  2174.   #
  2175.   Access=CPE
  2176.   Clock=Internal
  2177.   KBaud=64
  2178.   Flags=TX
  2179.   #
  2180.   # MTU=1500              # Maximum transmit IFrame length, default is 4096
  2181.   # T391=10               # T391 value    5 - 30, default is 10
  2182.   # T392=15               # T392 value    5 - 30, default is 15
  2183.   # N391=6                # N391 value    1 - 255, default is 6
  2184.   # N392=3                # N392 value    1 - 10, default is 3
  2185.   # N393=4                # N393 value    1 - 10, default is 4
  2186.  
  2187.   # Specified here, these set the defaults for all boards
  2188.   # CIRfwd=16             # CIR forward   1 - 64
  2189.   # Bc_fwd=16             # Bc forward    1 - 512
  2190.   # Be_fwd=0              # Be forward    0 - 511
  2191.   # CIRbak=16             # CIR backward  1 - 64
  2192.   # Bc_bak=16             # Bc backward   1 - 512
  2193.   # Be_bak=0              # Be backward   0 - 511
  2194.  
  2195.   #
  2196.   #
  2197.   # Device specific configuration
  2198.   #
  2199.   #
  2200.  
  2201.   #
  2202.   # The first device is a Sangoma S502E
  2203.   #
  2204.   [sdla0]
  2205.   Type=Sangoma            # Type of the device to configure, currently only
  2206.                           # SANGOMA is recognised
  2207.   #
  2208.   # These keys are specific to the 'Sangoma' type
  2209.   #
  2210.   # The type of Sangoma board - S502A, S502E, S508
  2211.   Board=S502E
  2212.   #
  2213.   # The name of the test firmware for the Sangoma board
  2214.   # Testware=/usr/src/frad-0.10/bin/sdla_tst.502
  2215.   #
  2216.   # The name of the FR firmware
  2217.   # Firmware=/usr/src/frad-0.10/bin/frm_rel.502
  2218.   #
  2219.   Port=360                # Port for this particular card
  2220.   Mem=C8                  # Address of memory window, A0-EE, depending on card
  2221.   IRQ=5                   # IRQ number, do not supply for S502A
  2222.   DLCIs=1                 # Number of DLCI's attached to this device
  2223.   DLCI_1=16               # DLCI #1's number, 16 - 991
  2224.   # DLCI_2=17
  2225.   # DLCI_3=18
  2226.   # DLCI_4=19
  2227.   # DLCI_5=20
  2228.   #
  2229.   # Specified here, these apply to this device only,
  2230.   # and override defaults from above
  2231.   #
  2232.   # Access=CPE            # CPE or NODE, default is CPE
  2233.   # Flags=TXIgnore,RXIgnore,BufferFrames,DropAborted,Stats,MCI,AutoDLCI
  2234.   # Clock=Internal        # External or Internal, default is Internal
  2235.   # Baud=128              # Specified baud rate of attached CSU/DSU
  2236.   # MTU=2048              # Maximum transmit IFrame length, default is 4096
  2237.   # T391=10               # T391 value    5 - 30, default is 10
  2238.   # T392=15               # T392 value    5 - 30, default is 15
  2239.   # N391=6                # N391 value    1 - 255, default is 6
  2240.   # N392=3                # N392 value    1 - 10, default is 3
  2241.   # N393=4                # N393 value    1 - 10, default is 4
  2242.  
  2243.   #
  2244.   # The second device is some other card
  2245.   #
  2246.   # [sdla1]
  2247.   # Type=FancyCard        # Type of the device to configure.
  2248.   # Board=                # Type of Sangoma board
  2249.   # Key=Value             # values specific to this type of device
  2250.  
  2251.   #
  2252.   # DLCI Default configuration parameters
  2253.   # These may be overridden in the DLCI specific configurations
  2254.   #
  2255.   CIRfwd=64               # CIR forward   1 - 64
  2256.   # Bc_fwd=16             # Bc forward    1 - 512
  2257.   # Be_fwd=0              # Be forward    0 - 511
  2258.   # CIRbak=16             # CIR backward  1 - 64
  2259.   # Bc_bak=16             # Bc backward   1 - 512
  2260.   # Be_bak=0              # Be backward   0 - 511
  2261.  
  2262.   #
  2263.   # DLCI Configuration
  2264.   # These are all optional. The naming convention is
  2265.   # [DLCI_D<devicenum>_<DLCI_Num>]
  2266.   #
  2267.  
  2268.   [DLCI_D1_16]
  2269.   # IP=
  2270.   # Net=
  2271.   # Mask=
  2272.   # Flags defined by Sangoma: TXIgnore,RXIgnore,BufferFrames
  2273.   # DLCIFlags=TXIgnore,RXIgnore,BufferFrames
  2274.   # CIRfwd=64
  2275.   # Bc_fwd=512
  2276.   # Be_fwd=0
  2277.   # CIRbak=64
  2278.   # Bc_bak=512
  2279.   # Be_bak=0
  2280.  
  2281.   [DLCI_D2_16]
  2282.   # IP=
  2283.   # Net=
  2284.   # Mask=
  2285.   # Flags defined by Sangoma: TXIgnore,RXIgnore,BufferFrames
  2286.   # DLCIFlags=TXIgnore,RXIgnore,BufferFrames
  2287.   # CIRfwd=16
  2288.   # Bc_fwd=16
  2289.   # Be_fwd=0
  2290.   # CIRbak=16
  2291.   # Bc_bak=16
  2292.   # Be_bak=0
  2293.  
  2294.   When you've built your /etc/frad/router.conf file the only step
  2295.   remaining is to configure the actual devices themselves. This is only
  2296.   a little trickier than a normal network device configuration, you need
  2297.   to remember to bring up the FRAD device before the DLCI encapsulation
  2298.   devices.
  2299.  
  2300.        # Configure the frad hardware and the DLCI parameters
  2301.        /sbin/fradcfg /etc/frad/router.conf || exit 1
  2302.        /sbin/dlcicfg file /etc/frad/router.conf
  2303.        #
  2304.        # Bring up the FRAD device
  2305.        ifconfig sdla0 up
  2306.        #
  2307.        # Configure the DLCI encapsulation interfaces and routing
  2308.        ifconfig dlci00 192.168.10.1 pointopoint 192.168.10.2 up
  2309.        route add -net 192.168.10.0 netmask 255.255.255.0 dlci00
  2310.        #
  2311.        ifconfig dlci01 192.168.11.1 pointopoint 192.168.11.2 up
  2312.        route add -net 192.168.11.0 netmask 255.255.255.0 dlci00
  2313.        #
  2314.        route add default dev dlci00
  2315.        #
  2316.  
  2317.   6.10.  IP Accounting
  2318.  
  2319.   The IP accounting features of the Linux kernel allow you to collect
  2320.   and analyse some network usage data. The data collected comprises the
  2321.   number of packets and the number of bytes accumulated since the
  2322.   figures were last reset. You may specify a variety of rules to
  2323.   categorise the figures to suit whatever purpose you may have.
  2324.  
  2325.   Kernel Compile Options:
  2326.  
  2327.        Networking options  --->
  2328.            [*] IP: accounting
  2329.  
  2330.   After you have compiled and installed the kernel you need to use the
  2331.   ipfwadm command to configure IP accounting. There are many different
  2332.   ways of breaking down the accounting information that you might
  2333.   choose.  I've picked a simple example of what might be useful to use,
  2334.   you should read the ipfwadm man page for more information.
  2335.  
  2336.   Scenario: You have a ethernet network that is linked to the internet
  2337.   via a PPP link. On the ethernet you have a machine that offers a
  2338.   number of services and that you are interested in knowing how much
  2339.   traffic is generated by each of telnet, rlogin, ftp and world wide web
  2340.   traffic.
  2341.  
  2342.   You might use a command set that looks like the following:
  2343.  
  2344.        #
  2345.        # Flush the accounting rules
  2346.        ipfwadm -A -f
  2347.        #
  2348.        # Add rules for local ethernet segment
  2349.        ipfwadm -A in -a -P tcp -D 44.136.8.96/29 20
  2350.        ipfwadm -A out -a -P tcp -S 44.136.8.96/29 20
  2351.        ipfwadm -A in -a -P tcp -D 44.136.8.96/29 23
  2352.        ipfwadm -A out -a -P tcp -S 44.136.8.96/29 23
  2353.        ipfwadm -A in -a -P tcp -D 44.136.8.96/29 80
  2354.        ipfwadm -A out -a -P tcp -S 44.136.8.96/29 80
  2355.        ipfwadm -A in -a -P tcp -D 44.136.8.96/29 513
  2356.        ipfwadm -A out -a -P tcp -S 44.136.8.96/29 513
  2357.        ipfwadm -A in -a -P tcp -D 44.136.8.96/29
  2358.        ipfwadm -A out -a -P tcp -D 44.136.8.96/29
  2359.        ipfwadm -A in -a -P udp -D 44.136.8.96/29
  2360.        ipfwadm -A out -a -P udp  -D 44.136.8.96/29
  2361.        ipfwadm -A in -a -P icmp -D 44.136.8.96/29
  2362.        ipfwadm -A out -a -P icmp -D 44.136.8.96/29
  2363.        #
  2364.        # Rules for default
  2365.        ipfwadm -A in -a -P tcp -D 0/0 20
  2366.        ipfwadm -A out -a -P tcp -S 0/0 20
  2367.        ipfwadm -A in -a -P tcp -D 0/0 23
  2368.        ipfwadm -A out -a -P tcp -S 0/0 23
  2369.        ipfwadm -A in -a -P tcp -D 0/0 80
  2370.        ipfwadm -A out -a -P tcp -S 0/0 80
  2371.        ipfwadm -A in -a -P tcp -D 0/0 513
  2372.        ipfwadm -A out -a -P tcp -S 0/0 513
  2373.        ipfwadm -A in -a -P tcp -D 0/0
  2374.        ipfwadm -A out -a -P tcp -D 0/0
  2375.        ipfwadm -A in -a -P udp -D 0/0
  2376.        ipfwadm -A out -a -P udp  -D 0/0
  2377.        ipfwadm -A in -a -P icmp -D 0/0
  2378.        ipfwadm -A out -a -P icmp -D 0/0
  2379.        #
  2380.        # List the rules
  2381.        ipfwadm -A -l -n
  2382.        #
  2383.  
  2384.   The last command lists each of the Accounting rules and displays the
  2385.   collected totals.
  2386.  
  2387.   An important point to note when analysing IP accounting is that totals
  2388.   for all rules that match will be incremented so that to obtain
  2389.   differential figures you need to perform appropriate maths. For
  2390.   example if I wanted to know how much data was not ftp, telnet, rlogin
  2391.   or www I would substract the individual totals from the rule that
  2392.   matches all ports.
  2393.  
  2394.   # ipfwadm -A -l -n
  2395.   IP accounting rules
  2396.    pkts bytes dir prot source               destination          ports
  2397.       0     0 in  tcp  0.0.0.0/0            44.136.8.96/29       * -> 20
  2398.       0     0 out tcp  44.136.8.96/29       0.0.0.0/0            20 -> *
  2399.       0     0 in  tcp  0.0.0.0/0            44.136.8.96/29       * -> 23
  2400.       0     0 out tcp  44.136.8.96/29       0.0.0.0/0            23 -> *
  2401.      10  1166 in  tcp  0.0.0.0/0            44.136.8.96/29       * -> 80
  2402.      10   572 out tcp  44.136.8.96/29       0.0.0.0/0            80 -> *
  2403.     242  9777 in  tcp  0.0.0.0/0            44.136.8.96/29       * -> 513
  2404.     220 18198 out tcp  44.136.8.96/29       0.0.0.0/0            513 -> *
  2405.     252 10943 in  tcp  0.0.0.0/0            44.136.8.96/29       * -> *
  2406.     231 18831 out tcp  0.0.0.0/0            44.136.8.96/29       * -> *
  2407.       0     0 in  udp  0.0.0.0/0            44.136.8.96/29       * -> *
  2408.       0     0 out udp  0.0.0.0/0            44.136.8.96/29       * -> *
  2409.       0     0 in  icmp 0.0.0.0/0            44.136.8.96/29       *
  2410.       0     0 out icmp 0.0.0.0/0            44.136.8.96/29       *
  2411.       0     0 in  tcp  0.0.0.0/0            0.0.0.0/0            * -> 20
  2412.       0     0 out tcp  0.0.0.0/0            0.0.0.0/0            20 -> *
  2413.       0     0 in  tcp  0.0.0.0/0            0.0.0.0/0            * -> 23
  2414.       0     0 out tcp  0.0.0.0/0            0.0.0.0/0            23 -> *
  2415.      10  1166 in  tcp  0.0.0.0/0            0.0.0.0/0            * -> 80
  2416.      10   572 out tcp  0.0.0.0/0            0.0.0.0/0            80 -> *
  2417.     243  9817 in  tcp  0.0.0.0/0            0.0.0.0/0            * -> 513
  2418.     221 18259 out tcp  0.0.0.0/0            0.0.0.0/0            513 -> *
  2419.     253 10983 in  tcp  0.0.0.0/0            0.0.0.0/0            * -> *
  2420.     231 18831 out tcp  0.0.0.0/0            0.0.0.0/0            * -> *
  2421.       0     0 in  udp  0.0.0.0/0            0.0.0.0/0            * -> *
  2422.       0     0 out udp  0.0.0.0/0            0.0.0.0/0            * -> *
  2423.       0     0 in  icmp 0.0.0.0/0            0.0.0.0/0            *
  2424.       0     0 out icmp 0.0.0.0/0            0.0.0.0/0            *
  2425.   #
  2426.  
  2427.   6.11.  IP Aliasing
  2428.  
  2429.   There are some applications where being able to configure multiple IP
  2430.   addresses to a single network device is useful. Internet Service
  2431.   Providers often use this facility to provide a `customised' to their
  2432.   World Wide Web and ftp offerings for their customers.
  2433.  
  2434.   Kernel Compile Options:
  2435.  
  2436.        Networking options  --->
  2437.            ....
  2438.            [*] Network aliasing
  2439.            ....
  2440.            <*> IP: aliasing support
  2441.  
  2442.   After compiling and installing your kernel with IP_Alias support
  2443.   configuration is very simple. The aliases are added to virtual network
  2444.   devices associated with the actual network device. A simple naming
  2445.   convention applies to these devices being <devname>:<virtual dev num>,
  2446.   e.g. eth0:0, ppp0:10 etc.
  2447.  
  2448.   For example, assume you have an ethernet network that supports two
  2449.   different IP subnetworks simultaneously and you wish your machine to
  2450.   have direct access to both, you could use something like:
  2451.  
  2452.        #
  2453.        # ifconfig eth0:0 192.168.1.1 netmask 255.255.255.0 up
  2454.        # route add -net 192.168.1.0 netmask 255.255.255.0 eth0:0
  2455.        #
  2456.        # ifconfig eth0:1 192.168.10.1 netmask 255.255.255.0 up
  2457.        # route add -net 192.168.10.0 netmask 255.255.255.0 eth0:0
  2458.        #
  2459.  
  2460.   To delete an alias you simply add a `-' to the end of its name and
  2461.   refer to it and is as simple as:
  2462.  
  2463.        # ifconfig eth0:0- 0
  2464.  
  2465.   All routes associated with that alias will also be deleted automati¡
  2466.   cally.
  2467.  
  2468.   6.12.  IP Firewall
  2469.  
  2470.   IP Firewall and Firewalling issues are covered in more depth in the
  2471.   Firewall-HOWTO <Firewall-HOWTO.html>. IP Firewalling allows you to
  2472.   secure your machine against unauthorised network access by filtering
  2473.   or allowing datagrams from or to IP addresses that you nominate. There
  2474.   are three different classes of rules, incoming filtering, outgoing
  2475.   filtering and forwarding filtering. Incoming rules are applied to
  2476.   datagrams that are received by a network device. Outgoing rules are
  2477.   applied to datagrams that are to be transmitted by a network device.
  2478.   Forwarding rules are applied to datagrams that are received and are
  2479.   not for this machine, ie datagrams that would be routed.
  2480.  
  2481.   Kernel Compile Options:
  2482.  
  2483.        Networking options  --->
  2484.            [*] Network firewalls
  2485.            ....
  2486.            [*] IP: forwarding/gatewaying
  2487.            ....
  2488.            [*] IP: firewalling
  2489.            [ ] IP: firewall packet logging
  2490.  
  2491.   Configuration of the IP firewall rules is performed using the ipfwadm
  2492.   command. As I mentioned earlier, security is not something I am expert
  2493.   at, so while I will present an example you can use, you should do your
  2494.   own research and develop your own rules if security is important to
  2495.   you.
  2496.  
  2497.   Probably the most common use of IP firewall is when you are using your
  2498.   linux machine as a router and firewall gateway to protect your local
  2499.   network from unauthorised access from outside your network.
  2500.  
  2501.   The following configuration is based on a contribution from Arnt
  2502.   Gulbrandsen, <agulbra@troll.no>.
  2503.  
  2504.   The example describes the configuration of the firewall rules on the
  2505.   Linux firewall/router machine illustrated in this diagram:
  2506.        -                                   -
  2507.         \                                  | 172.16.37.0
  2508.          \                                 |   /255.255.255.0
  2509.           \                 ---------      |
  2510.            |  172.16.174.30 | Linux |      |
  2511.        NET =================|  f/w  |------|    ..37.19
  2512.            |    PPP         | router|      |  --------
  2513.           /                 ---------      |--| Mail |
  2514.          /                                 |  | /DNS |
  2515.         /                                  |  --------
  2516.        -                                   -
  2517.  
  2518.   The following commands would normally be placed in an rc file so that
  2519.   they were automatically started each time the system boots. For
  2520.   maximum security they would be performed after the network interfaces
  2521.   are configured, but before the interfaces are actually brought up to
  2522.   prevent anyone gaining access while the firewall machine is rebooting.
  2523.  
  2524.   #!/bin/sh
  2525.  
  2526.   # Flush the 'Forwarding' rules table
  2527.   # Change the default policy to 'accept'
  2528.   #
  2529.   /sbin/ipfwadm -F -f
  2530.   /sbin/ipfwadm -F -p accept
  2531.   #
  2532.   # .. and for 'Incoming'
  2533.   #
  2534.   /sbin/ipfwadm -I -f
  2535.   /sbin/ipfwadm -I -p accept
  2536.  
  2537.   # First off, seal off the PPP interface
  2538.   # I'd love to use '-a deny' instead of '-a reject -y' but then it
  2539.   # would be impossible to originate connections on that interface too.
  2540.   # The -o causes all rejected datagrams to be logged. This trades
  2541.   # disk space against knowledge of an attack of configuration error.
  2542.   #
  2543.   /sbin/ipfwadm -I -a reject -y -o -P tcp -S 0/0 -D 172.16.174.30
  2544.  
  2545.   # Throw away certain kinds of obviously forged packets right away:
  2546.   # Nothing should come from multicast/anycast/broadcast addresses
  2547.   #
  2548.   /sbin/ipfwadm -F -a deny -o -S 224.0/3 -D 172.16.37.0/24
  2549.   #
  2550.   # and nothing coming from the loopback network should ever be
  2551.   # seen on a wire
  2552.   #
  2553.   /sbin/ipfwadm -F -a deny -o -S 127.0/8 -D 172.16.37.0/24
  2554.  
  2555.   # accept incoming SMTP and DNS connections, but only
  2556.   # to the Mail/Name Server
  2557.   #
  2558.   /sbin/ipfwadm -F -a accept -P tcp -S 0/0 -D 172.16.37.19 25 53
  2559.   #
  2560.   # DNS uses UDP as well as TCP, so allow that too
  2561.   # for questions to our name server
  2562.   #
  2563.   /sbin/ipfwadm -F -a accept -P udp -S 0/0 -D 172.16.37.19 53
  2564.   #
  2565.   # but not "answers" coming to dangerous ports like NFS and
  2566.   # Larry McVoy's NFS extension.  If you run squid, add its port here.
  2567.   #
  2568.   /sbin/ipfwadm -F -a deny -o -P udp -S 0/0 53 \
  2569.           -D 172.16.37.0/24 2049 2050
  2570.  
  2571.   # answers to other user ports are okay
  2572.   #
  2573.   /sbin/ipfwadm -F -a accept -P udp -S 0/0 53 \
  2574.           -D 172.16.37.0/24 53 1024:65535
  2575.  
  2576.   # Reject incoming connections to identd
  2577.   # We use 'reject' here so that the connecting host is told
  2578.   # straight away not to bother continuing, otherwise we'd experience
  2579.   # delays while ident timed out.
  2580.   #
  2581.   /sbin/ipfwadm -F -a reject -o -P tcp -S 0/0 -D 172.16.37.0/24 113
  2582.  
  2583.   # Accept some common service connections from the 192.168.64 and
  2584.   # 192.168.65 networks, they are friends that we trust.
  2585.   #
  2586.   /sbin/ipfwadm -F -a accept -P tcp -S 192.168.64.0/23 \
  2587.           -D 172.16.37.0/24 20:23
  2588.  
  2589.   # accept and pass through anything originating inside
  2590.   #
  2591.   /sbin/ipfwadm -F -a accept -P tcp -S 172.16.37.0/24 -D 0/0
  2592.  
  2593.   # deny most other incoming TCP connections and log them
  2594.   # (append 1:1023 if you have problems with ftp not working)
  2595.   #
  2596.   /sbin/ipfwadm -F -a deny -o -y -P tcp -S 0/0 -D 172.16.37.0/24
  2597.  
  2598.   # ... for UDP too
  2599.   #
  2600.   /sbin/ipfwadm -F -a deny -o -P udp -S 0/0 -D 172.16.37.0/24
  2601.  
  2602.   Good firewall configurations are a little tricky. This example should
  2603.   be a reasonable starting point for you. The ipfwadm manual page offers
  2604.   some assistance in how to use the tool. If you intend to configure a
  2605.   firewall, be sure to ask around and get as much advice from sources
  2606.   you consider reliable and get someone to test/sanity check your
  2607.   configuration from the outside.
  2608.  
  2609.   6.13.  IPIP Encapsulation
  2610.  
  2611.   Why would you want to encapsulate IP datagrams within IP datagrams? It
  2612.   must seem an odd thing to do if you've never seen an application of it
  2613.   before.  Ok, here are a couple of common places where it is used:
  2614.   Mobile-IP and IP-Multicast. What is perhaps the most widely spread use
  2615.   of it though is also the least well known, Amateur Radio.
  2616.  
  2617.   Kernel Compile Options:
  2618.  
  2619.        Networking options  --->
  2620.            [*] TCP/IP networking
  2621.            [*] IP: forwarding/gatewaying
  2622.            ....
  2623.            <*> IP: tunneling
  2624.  
  2625.   IP tunnel devices are called `tunl0', `tunl1' etc.
  2626.  
  2627.   "But why ?". Ok, ok. Conventional IP routing rules mandate that an IP
  2628.   network comprises a network address and a network mask. This produces
  2629.   a series of contiguous addresses that may all be routed via a single
  2630.   routing entry.  This is very convenient, but it means that you may
  2631.   only use any particular IP address while you are connected to the
  2632.   particular piece of network to which it belongs. In most instances
  2633.   this is ok, but if you are a mobile netizen then you may not be able
  2634.   to stay connected to the one place all the time. IP/IP encapsulation
  2635.   (IP tunneling) allows you to overcome this restriction by allowing
  2636.   datagrams destined for your IP address to be wrapped up and redirected
  2637.   to another IP address. If you know that you're going to be operating
  2638.   from some other IP network for some time you can set up a machine on
  2639.   your home network to accept datagrams to your IP address and redirect
  2640.   them to the address that you will actually be using temporarily.
  2641.  
  2642.   6.13.1.  A tunneled network configuration.
  2643.  
  2644.   As always, I believe a diagram will save me lots of confusing text, so
  2645.   here is one:
  2646.  
  2647.         192.168.1/24                          192.168.2/24
  2648.  
  2649.             -                                     -
  2650.             |      ppp0 =            ppp0 =       |
  2651.             |  aaa.bbb.ccc.ddd  fff.ggg.hhh.iii   |
  2652.             |                                     |
  2653.             |   /-----\                 /-----\   |
  2654.             |   |     |       //        |     |   |
  2655.             |---|  A  |------//---------|  B  |---|
  2656.             |   |     |     //          |     |   |
  2657.             |   \-----/                 \-----/   |
  2658.             |                                     |
  2659.             -                                     -
  2660.  
  2661.   The diagram illustrates another possible reason to use IPIP
  2662.   encapsulation, virtual private networking. This example presupposes
  2663.   that you have two machines each with a simple dial up internet
  2664.   connection. Each host is allocated just a single IP address. Behind
  2665.   each of these machines are some private local area networks configured
  2666.   with reserved IP network addresses. Suppose that you want to allow any
  2667.   host on network A to connect to any host on network B, just as if they
  2668.   were properly connected to the Internet with a network route. IPIP
  2669.   encapsulation will allow you to do this. Note, encapsulation does not
  2670.   solve the problem of how you get the hosts on networks A and B to talk
  2671.   to any other on the Internet, you still need tricks like IP Masquerade
  2672.   for that.  Encapsulation is normally performed by machine functioning
  2673.   as routers.
  2674.  
  2675.   Linux router `A' would be configured with:
  2676.  
  2677.        #
  2678.        PATH=/sbin:/usr/sbin
  2679.        #
  2680.        # Ethernet configuration
  2681.        ifconfig eth0 192.168.1.1 netmask 255.255.255.0 up
  2682.        route add -net 192.168.1.0 netmask 255.255.255.0 eth0
  2683.        #
  2684.        # ppp0 configuration (start ppp link, set default route)
  2685.        pppd
  2686.        route add default ppp0
  2687.        #
  2688.        # Tunnel device configuration
  2689.        ifconfig tunl0 192.168.1.1 up
  2690.        route add -net 192.168.2.0 netmask 255.255.255.0 gw fff.ggg.hhh.iii tunl0
  2691.  
  2692.   Linux router `B' would be configured with:
  2693.  
  2694.   #
  2695.   PATH=/sbin:/usr/sbin
  2696.   #
  2697.   # Ethernet configuration
  2698.   ifconfig eth0 192.168.2.1 netmask 255.255.255.0 up
  2699.   route add -net 192.168.2.0 netmask 255.255.255.0 eth0
  2700.   #
  2701.   # ppp0 configuration (start ppp link, set default route)
  2702.   pppd
  2703.   route add default ppp0
  2704.   #
  2705.   # Tunnel device configuration
  2706.   ifconfig tunl0 192.168.2.1 up
  2707.   route add -net 192.168.1.0 netmask 255.255.255.0 gw aaa.bbb.ccc.ddd tunl0
  2708.  
  2709.   The command:
  2710.  
  2711.        route add -net 192.168.1.0 netmask 255.255.255.0 gw aaa.bbb.ccc.ddd tunl0
  2712.  
  2713.   reads: `Send any datagrams destined for 192.168.1.0/24 inside an IPIP
  2714.   encap datagram with a destination address of aaa.bbb.ccc.ddd'.
  2715.  
  2716.   Note that the configurations are reciprocated at either end. The
  2717.   tunnel device uses the `gw' in the route as the destination of the IP
  2718.   datagram in which it will place the datagram it has received to route.
  2719.   That machine must know how to decapsulate IPIP datagrams, that is, it
  2720.   must also be configured with a tunnel device.
  2721.  
  2722.   6.13.2.  A tunneled host configuration.
  2723.  
  2724.   It doesn't have to be a whole network you route. You could for example
  2725.   route just a single IP address. In that instance you might configure
  2726.   the tunl device on the `remote' machine with its home IP address and
  2727.   at the A end just use a host route (and Proxy Arp) rather than a
  2728.   network route via the tunnel device. Let's redraw and modify our
  2729.   configuration appropriately. Now we have just host `B' which to want
  2730.   to act and behave as if it is both fully connected to the Internet and
  2731.   also part of the remote network supported by host `A':
  2732.  
  2733.         192.168.1/24
  2734.  
  2735.             -
  2736.             |      ppp0 =                ppp0 =
  2737.             |  aaa.bbb.ccc.ddd      fff.ggg.hhh.iii
  2738.             |
  2739.             |   /-----\                 /-----\
  2740.             |   |     |       //        |     |
  2741.             |---|  A  |------//---------|  B  |
  2742.             |   |     |     //          |     |
  2743.             |   \-----/                 \-----/
  2744.             |                      also: 192.168.1.12
  2745.             -
  2746.  
  2747.   Linux router `A' would be configured with:
  2748.  
  2749.        #
  2750.        PATH=/sbin:/usr/sbin
  2751.        #
  2752.        # Ethernet configuration
  2753.        ifconfig eth0 192.168.1.1 netmask 255.255.255.0 up
  2754.        route add -net 192.168.1.0 netmask 255.255.255.0 eth0
  2755.        #
  2756.        # ppp0 configuration (start ppp link, set default route)
  2757.        pppd
  2758.        route add default ppp0
  2759.        #
  2760.        # Tunnel device configuration
  2761.        ifconfig tunl0 192.168.1.1 up
  2762.        route add -host 192.168.1.12 gw fff.ggg.hhh.iii tunl0
  2763.        #
  2764.        # Proxy ARP for the remote host
  2765.        arp -s 192.168.1.12 xx:xx:xx:xx:xx:xx pub
  2766.  
  2767.   Linux host `B' would be configured with:
  2768.  
  2769.        #
  2770.        PATH=/sbin:/usr/sbin
  2771.        #
  2772.        # ppp0 configuration (start ppp link, set default route)
  2773.        pppd
  2774.        route add default ppp0
  2775.        #
  2776.        # Tunnel device configuration
  2777.        ifconfig tunl0 192.168.1.12 up
  2778.        route add -net 192.168.1.0 netmask 255.255.255.0 gw aaa.bbb.ccc.ddd tunl0
  2779.  
  2780.   This sort of configuration is more typical of a Mobile-IP application.
  2781.   Where a single host wants to roam around the Internet and maintain a
  2782.   single usable IP address the whole time. You should refer to the
  2783.   Mobile-IP section for more information on how that is handled in
  2784.   practice.
  2785.  
  2786.   6.14.  IPX (AF_IPX)
  2787.  
  2788.   The IPX protocol is most commonly utilised in Novell NetWare(tm) local
  2789.   area network environments. Linux includes support for this protocol
  2790.   and may be configured to act as a network endpoint, or as a router for
  2791.   IPX.
  2792.  
  2793.   Kernel Compile Options:
  2794.  
  2795.        Networking options  --->
  2796.            [*] The IPX protocol
  2797.            [ ] Full internal IPX network
  2798.  
  2799.   The IPX protocol and the NCPFS are covered in greater depth in the
  2800.   IPX-HOWTO <IPX-HOWTO.html>.
  2801.  
  2802.   6.15.  IPv6
  2803.  
  2804.   Just when you thought you were beginning to understand IP networking
  2805.   the rules get changed! IPv6 is the shorthand notation for version 6 of
  2806.   the Internet Protocol. IPv6 was developed primarily to overcome the
  2807.   concerns in the Internet community that there would soon be a shortage
  2808.   of IP addresses to allocate. IPv6 addresses are 16 bytes long (128
  2809.   bits). IPv6 incorporates a number of other changes, mostly
  2810.   simplifications, that will make IPv6 networks more managable than IPv4
  2811.   networks.
  2812.  
  2813.   Linux already has a working, but not completed, IPv6 implementation in
  2814.   the 2.1.* series kernels.
  2815.  
  2816.   If you wish to experiment with this next generation Internet
  2817.   technology, or have a requirement for it, then you should read the
  2818.   IPv6-FAQ which is available from www.terra.net
  2819.   <http://www.terra.net/ipv6/>.
  2820.  
  2821.   6.16.  ISDN
  2822.  
  2823.   The Integrated Services Digital Network (ISDN) is a series of
  2824.   standards that specify a general purpose switched digital data
  2825.   network. An ISDN `call' creates a synchronous point to point data
  2826.   service to the destination. ISDN is generally delivered on a high
  2827.   speed link that is broken down into a number of discrete channels.
  2828.   There are two different types of channels, the `B Channels' which will
  2829.   actually carry the user data and a single channel called the `D
  2830.   channel' which is used to send control information to the ISDN
  2831.   exchange to establish calls and other functions. In Australia for
  2832.   example, ISDN may be delivered on a 2Mbps link that is broken into 30
  2833.   discreet 64kbps B channels with one 64kbps D channel. Any number of
  2834.   channels may be used at a time and in any combination. You could for
  2835.   example establish 30 seperate calls to 30 different destinations at
  2836.   64kbps each, or you could establish 15 calls to 15 different
  2837.   destinations at 128kbps each (two channels used per call), or just a
  2838.   small number of calls and leave the rest idle. A channel may be used
  2839.   for either incoming or outgoing calls. The original intention of ISDN
  2840.   was to allow Telecommunications companies to provide a single data
  2841.   service which could deliver either telephone (via digitised voice) or
  2842.   data services to your home or business without requiring you to make
  2843.   any special configuration changes.
  2844.  
  2845.   There are a few different ways to connect your computer to an ISDN
  2846.   service.  One way is to use a device called a `Terminal Adaptor' which
  2847.   plugs into the Network Terminating Unit that you telecommunications
  2848.   carrier will have installed when you got your ISDN service and
  2849.   presents a number of serial interfaces. One of those interfaces is
  2850.   used to enter commands to establish calls and configuration and the
  2851.   others are actually connected to the network devices that will use the
  2852.   data circuits when they are established. Linux will work in this sort
  2853.   of configuration without modification, you just treat the port on the
  2854.   Terminal Adaptor like you would treat any other serial device.
  2855.   Another way, which is the way the kernel ISDN support is designed for
  2856.   allows you to install an ISDN card into your Linux machine and then
  2857.   has your Linux software handle the protocols and make the calls
  2858.   itself.
  2859.  
  2860.   Kernel Compile Options:
  2861.  
  2862.   ISDN subsystem  --->
  2863.           <*> ISDN support
  2864.           [ ] Support synchronous PPP
  2865.           [ ] Support audio via ISDN
  2866.           < > ICN 2B and 4B support
  2867.           < > PCBIT-D support
  2868.           < > Teles/NICCY1016PC/Creatix support
  2869.  
  2870.   The Linux implementation of ISDN support a number of different types
  2871.   of internal ISDN cards. These are those listed in the kernel
  2872.   configuration options:
  2873.  
  2874.   ╖  ICN 2B and 4B
  2875.  
  2876.   ╖  Octal PCBIT-D
  2877.  
  2878.   ╖  Teles ISDN-cards and compatibles
  2879.  
  2880.      Some of these cards require software to be downloaded to them to
  2881.      make them operational. There is a seperate utility to do this with.
  2882.  
  2883.   Full details on how to configure the Linux ISDN support is available
  2884.   from the /usr/src/linux/Documentation/isdn/ directory and an FAQ
  2885.   dedicated to isdn4linux is available at www.lrz-muenchen.de
  2886.   <http://www.lrz-muenchen.de/~ui161ab/www/isdn/>.  (You can click on
  2887.   the english flag to get an english version).
  2888.  
  2889.   A note about PPP. The PPP suite of protocols will operate over either
  2890.   asynchronous or synchronous serial lines. The commonly distributed PPP
  2891.   daemon for Linux `pppd' supports only asynchronous mode. If you wish
  2892.   to run the PPP protocols over your ISDN service you need a specially
  2893.   modified version. Details of where to find it are available in the
  2894.   documentation referred to above.
  2895.  
  2896.   6.17.  IP Masquerade
  2897.  
  2898.   Many people have a simple dialup account to connect to the Internet.
  2899.   Nearly everybody using this sort of configuration is allocated a
  2900.   single IP address by the Internet Service Provider. This is normally
  2901.   enough to allow only one host full access to the network. IP
  2902.   Masquerade is a clever trick that enables you to have many machines
  2903.   make use of that one IP address, by causing the other hosts to look
  2904.   like, hence the term masquerade, the machine supporting the dialup
  2905.   connection. There is a small caveat and that is that the masqerade
  2906.   function nearly always works only in one direction, that is the
  2907.   masqueraded hosts can make calls out, but they cannot accept or
  2908.   receive network connections from remote hosts. This means that some
  2909.   network services do not work such as talk and others such as ftp must
  2910.   be configured to operate in passive (PASV) mode to operate.
  2911.   Fortunately the most common network services such as telnet, World
  2912.   Wide Web and irc do work just fine.
  2913.  
  2914.   Kernel Compile Options:
  2915.  
  2916.   Code maturity level options  --->
  2917.       [*] Prompt for development and/or incomplete code/drivers
  2918.   Networking options  --->
  2919.       [*] Network firewalls
  2920.       ....
  2921.       [*] TCP/IP networking
  2922.       [*] IP: forwarding/gatewaying
  2923.       ....
  2924.       [*] IP: masquerading (EXPERIMENTAL)
  2925.  
  2926.   Normally you have your linux machine supporting a slip or PPP dialup
  2927.   line just as it would if it were a standalone machine. Additionally it
  2928.   would have another network device configured, perhaps an ethernet,
  2929.   configured with one of the reserved network addresses. The hosts to be
  2930.   masqueraded would be on this second network. Each of these hosts would
  2931.   have the IP address of the ethernet port of the linux machine set as
  2932.   their default gateway or router.
  2933.  
  2934.   A typical configuration might look something like this:
  2935.  
  2936.        -                                   -
  2937.         \                                  | 192.168.1.0
  2938.          \                                 |   /255.255.255.0
  2939.           \                 ---------      |
  2940.            |                | Linux | .1.1 |
  2941.        NET =================| masq  |------|
  2942.            |    PPP/slip    | router|      |  --------
  2943.           /                 ---------      |--| host |
  2944.          /                                 |  |      |
  2945.         /                                  |  --------
  2946.        -                                   -
  2947.  
  2948.   The most relevant commands for this configuration are:
  2949.  
  2950.        # Network route for ethernet
  2951.        route add -net 192.168.1.0 netmask 255.255.255.0 eth0
  2952.        #
  2953.        # Default route to the rest of the internet.
  2954.        route add default ppp0
  2955.        #
  2956.        # Cause all hosts on the 192.168.1/24 network to be masqueraded.
  2957.        ipfwadm -F -a m -S 192.168.1.0/24 -D 0.0.0.0/0
  2958.  
  2959.   You can get more information on the Linux IP Masquerade feature from
  2960.   the IP Masquerade Resource Page <http://www.hwy401.com/achau/ipmasq/>
  2961.  
  2962.   6.18.  IP Transparent Proxy
  2963.  
  2964.   IP transparent proxy is a feature that enables you to redirect servers
  2965.   or services destined for another machine to those services on this
  2966.   machine.  Typically this would be useful where you have a linux
  2967.   machine as a router and also provides a proxy server. You would
  2968.   redirect all connections destined for that service remotely to the
  2969.   local proxy server.
  2970.   Kernel Compile Options:
  2971.  
  2972.        Code maturity level options  --->
  2973.                [*] Prompt for development and/or incomplete code/drivers
  2974.        Networking options  --->
  2975.                [*] Network firewalls
  2976.                ....
  2977.                [*] TCP/IP networking
  2978.                ....
  2979.                [*] IP: firewalling
  2980.                ....
  2981.                [*] IP: transparent proxy support (EXPERIMENTAL)
  2982.  
  2983.   Configuration of the transparent proxy feature is performed using the
  2984.   ipfwadm command.
  2985.  
  2986.   An example that might be useful is as follows:
  2987.  
  2988.        ipfwadm -I -a accept -D 0/0 80 -r 8080
  2989.  
  2990.   This example will cause any connection attempts to port 80 (www) on
  2991.   any host to be redirected to port 8080 on this host. This could be
  2992.   used to ensure that all WWW traffic from your network is automatically
  2993.   directed to a local WWW cache program.
  2994.  
  2995.   6.19.  Mobile IP
  2996.  
  2997.   The term "IP mobility" describes the ability of a host that is able to
  2998.   move its network connection from one point on the Internet to another
  2999.   without changing its IP address or losing connectivity. Usually when
  3000.   an IP host changes its point of connectivity it must also change its
  3001.   IP address.  IP Mobility overcomes this problem by allocating a fixed
  3002.   IP address to the mobile host and using IP encapsulation (tunneling)
  3003.   with automatic routing to ensure that datagrams destined for it are
  3004.   routed to the actual IP address it is currently using.
  3005.  
  3006.   A project is underway to provide a complete set of IP mobility tools
  3007.   for Linux.  The Status of the project and tools may be obtained from
  3008.   the: Linux Mobile IP Home Page
  3009.   <http://anchor.cs.binghamton.edu/~mobileip/>.
  3010.  
  3011.   6.20.  Multicast
  3012.  
  3013.   IP Multicast allows an arbitrary number of IP hosts on disparate IP
  3014.   networks to have IP datagrams simultaneously routed to them. This
  3015.   mechanism is exploited to provide Internet wide "broadcast" material
  3016.   such as audio and video transmissions and other novel applications.
  3017.  
  3018.   Kernel Compile Options:
  3019.  
  3020.        Networking options  --->
  3021.                [*] TCP/IP networking
  3022.                ....
  3023.                [*] IP: multicasting
  3024.  
  3025.   A suite of tools and some minor network configuration is required. One
  3026.   source of information on how to install and configure these for Linux
  3027.   is provided at www.teksouth.com
  3028.   <http://www.teksouth.com/linux/multicast/>.
  3029.  
  3030.   6.21.  NAT - Network Address Translation
  3031.  
  3032.   The IP Network Address Translation facility is pretty much the
  3033.   standardised big brother of the Linux IP Masquerade facility. It is
  3034.   specified in some detail in RFC-1631 at your nearest RFC archive. NAT
  3035.   provides features that IP-Masquerade does not that make it eminently
  3036.   more suitable for use in corporate firewall router designs and larger
  3037.   scale installations.
  3038.  
  3039.   An alpha implementation of NAT for Linux 2.0.29 kernel has been
  3040.   developed by Michael.Hasenstein, Michael.Hasenstein@informatik.tu-
  3041.   chemnitz.de. Michaels documentation and implementation are available
  3042.   from:
  3043.  
  3044.   Linux IP Network Address Web Page <http://www.csn.tu-
  3045.   chemnitz.de/HyperNews/get/linux-ip-nat.html>
  3046.  
  3047.   Newer Linux 2.1.* kernels also include some NAT functionality in the
  3048.   routing algorithm.
  3049.  
  3050.   6.22.  NetRom (AF_NETROM)
  3051.  
  3052.   NetRom device names are `nr0', `nr1', etc.
  3053.  
  3054.   Kernel Compile Options:
  3055.  
  3056.        Networking options  --->
  3057.            [*] Amateur Radio AX.25 Level 2
  3058.            [*] Amateur Radio NET/ROM
  3059.  
  3060.   The AX25, Netrom and Rose protocols are covered by the AX25-HOWTO
  3061.   <AX25-HOWTO.html>.  These protocols are used by Amateur Radio Opera¡
  3062.   tors world wide in packet radio experimentation.
  3063.  
  3064.   Most of the work for implementation of these protocols has been done
  3065.   by Jonathon Naylor, jsn@cs.nott.ac.uk.
  3066.  
  3067.   6.23.  PLIP
  3068.  
  3069.   PLIP device names are `plip0', `plip1 and plip2.
  3070.  
  3071.   Kernel Compile Options:
  3072.  
  3073.        Networking options  --->
  3074.            <*> PLIP (parallel port) support
  3075.  
  3076.   plip (Parallel Line IP), is like SLIP, in that it is used for
  3077.   providing a point to point network connection between two machines,
  3078.   except that it is designed to use the parallel printer ports on your
  3079.   machine instead of the serial ports (a cabling diagram in included in
  3080.   the cabling diagram section later in this document). Because it is
  3081.   possible to transfer more than one bit at a time with a parallel port,
  3082.   it is possible to attain higher speeds with the plip interface than
  3083.   with a standard serial device.  In addition, even the simplest of
  3084.   parallel ports, printer ports, can be used in lieu of you having to
  3085.   purchase comparatively expensive 16550AFN UART's for your serial
  3086.   ports. PLIP uses a lot of CPU compared to a serial link and is most
  3087.   certainly not a good option if you can obtain some cheap ethernet
  3088.   cards, but it will work when nothing else is available and will work
  3089.   quite well.  You should expect a data transfer rate of about 20
  3090.   kilobytes per second when a link is running well.
  3091.  
  3092.   The PLIP device drivers competes with the parallel device driver for
  3093.   the parallel port hardware. If you wish to use both drivers then you
  3094.   should compile them both as modules to ensure that you are able to
  3095.   select which port you want to use for PLIP and which ports you want
  3096.   for the printer driver.  Refer to the Modules-HOWTO <Modules-
  3097.   HOWTO.html> for more information on kernel module configuration.
  3098.  
  3099.   Please note that some laptops use chipsets that will not work with
  3100.   PLIP because they do not allow some combinations of signals that PLIP
  3101.   relies on, that printers don't use.
  3102.  
  3103.   The Linux plip interface is compatible with the Crynwyr Packet Driver
  3104.   PLIP and this will mean that you can connect your Linux machine to a
  3105.   DOS machine running any other sort of tcp/ip software via plip.
  3106.  
  3107.   In the 2.0.* series kernel the plip devices are mapped to i/o port and
  3108.   IRQ as follows:
  3109.  
  3110.        device  i/o     IRQ
  3111.        ------  -----   ---
  3112.        plip0   0x3bc   5
  3113.        plip1   0x378   7
  3114.        plip2   0x278   2
  3115.  
  3116.   If your parallel ports don't match any of the above combinations then
  3117.   you can change the IRQ of a port using the ifconfig command using the
  3118.   `irq' parameter. Be sure to enable IRQ's on your printer ports in your
  3119.   ROM BIOS if it supports this option.
  3120.  
  3121.   In late 2.1.* series kernel with Plug'n'Play support the plip devices
  3122.   are allocated sequentially as they are detected just like the ethernet
  3123.   devices with plip0 being the first allocated.
  3124.  
  3125.   When compiling the kernel, there is only one file that might need to
  3126.   be looked at to configure plip. That file is
  3127.   /usr/src/linux/driver/net/CONFIG and it contains plip timers in
  3128.   milliseconds. The defaults are probably ok in most cases. You will
  3129.   probably need to increase them if you have an especially slow
  3130.   computer, in which case the timers to increase are actually on the
  3131.   other computer.  A program called plipconfig exists that allows you to
  3132.   change these timer settings without recompiling your kernel. It is
  3133.   supplied with many Linux distributions.
  3134.  
  3135.   To configure a plip interface, you will need to add the following
  3136.   lines to your network rc file:
  3137.  
  3138.   #
  3139.   # Attach a PLIP interface
  3140.   #
  3141.   #  configure first parallel port as a plip device
  3142.   /sbin/ifconfig plip0 IPA.IPA.IPA.IPA pointopoint IPR.IPR.IPR.IPR up
  3143.   #
  3144.   # End plip
  3145.  
  3146.   Where:
  3147.  
  3148.      IPA.IPA.IPA.IPA
  3149.         represents your IP address.
  3150.  
  3151.      IPR.IPR.IPR.IPR
  3152.         represents the IP address of the remote machine.
  3153.  
  3154.   The pointopoint parameter has the same meaning as for SLIP, in that it
  3155.   specifies the address of the machine at the other end of the link.
  3156.  
  3157.   In almost all respects you can treat a plip interface as though it
  3158.   were a SLIP interface, except that neither dip nor slattach need be,
  3159.   nor can be, used.
  3160.  
  3161.   Further information on PLIP may be obtained from the PLIP-mini-HOWTO
  3162.   <mini/PLIP>
  3163.  
  3164.   6.24.  PPP
  3165.  
  3166.   PPP devices names are `ppp0', `ppp1, etc. Devices are numbered
  3167.   sequentially with the first device configured receiving `0'.
  3168.  
  3169.   Kernel Compile Options:
  3170.  
  3171.        Networking options  --->
  3172.            <*> PPP (point-to-point) support
  3173.  
  3174.   PPP configuration is covered in detail in the PPP-HOWTO <PPP-
  3175.   HOWTO.html>.
  3176.  
  3177.   6.24.1.  Maintaining a permanent connection to the net with pppd.
  3178.  
  3179.   If you are fortunate enough to have a semi permanent connection to the
  3180.   net and would like to have your machine automatically redial your PPP
  3181.   connection if it is lost then here is a simple trick to do so.
  3182.  
  3183.   Configure PPP such that it can be started by the root user by issuing
  3184.   the command:
  3185.  
  3186.        # pppd
  3187.  
  3188.   Be sure that you have the `-detach' option configured in your
  3189.   /etc/ppp/options file. Then, insert the following line into your
  3190.   /etc/inittab file, down with the getty definitions:
  3191.        pd:23:respawn:/usr/sbin/pppd
  3192.  
  3193.   This will cause the init program to spawn and monitor the pppd program
  3194.   and automatically restart it if it dies.
  3195.  
  3196.   6.25.  Rose protocol (AF_ROSE)
  3197.  
  3198.   Rose device names are `rs0', `rs1', etc. in 2.1.* kernels.  Rose is
  3199.   available in the 2.1.* kernels.
  3200.  
  3201.   Kernel Compile Options:
  3202.  
  3203.        Networking options  --->
  3204.            [*] Amateur Radio AX.25 Level 2
  3205.            <*> Amateur Radio X.25 PLP (Rose)
  3206.  
  3207.   The AX25, Netrom and Rose protocols are covered by the AX25-HOWTO
  3208.   <AX25-HOWTO.html>.  These protocols are used by Amateur Radio Opera¡
  3209.   tors world wide in packet radio experimentation.
  3210.  
  3211.   Most of the work for implementation of these protocols has been done
  3212.   by Jonathon Naylor, jsn@cs.nott.ac.uk.
  3213.  
  3214.   6.26.  SAMBA - `NetBEUI', `NetBios' support.
  3215.  
  3216.   SAMBA is an implementation of the Session Management Block protocol.
  3217.   Samba allows Microsoft and other systems to mount and use your disks
  3218.   and printers.
  3219.  
  3220.   SAMBA and its configuration are covered in detail in the SMB-HOWTO
  3221.   <SMB-HOWTO.html>.
  3222.  
  3223.   6.27.  SLIP client
  3224.  
  3225.   SLIP devices are named `sl0', `sl1' etc. with the first device
  3226.   configured being assigned `0' and the rest incrementing sequentially
  3227.   as they are configured.
  3228.  
  3229.   Kernel Compile Options:
  3230.  
  3231.        Network device support  --->
  3232.            [*] Network device support
  3233.            <*> SLIP (serial line) support
  3234.            [ ]  CSLIP compressed headers
  3235.            [ ]  Keepalive and linefill
  3236.            [ ]  Six bit SLIP encapsulation
  3237.  
  3238.   SLIP (Serial Line Internet Protocol) allows you to use tcp/ip over a
  3239.   serial line, be that a phone line with a dialup modem, or a leased
  3240.   line of some sort.  Of course to use SLIP you need access to a SLIP-
  3241.   server in your area. Many universities and businesses provide SLIP
  3242.   access all over the world.
  3243.   Slip uses the serial ports on your machine to carry IP datagrams. To
  3244.   do this it must take control of the serial device. Slip device names
  3245.   are named sl0, sl1 etc. How do these correspond to your serial devices
  3246.   ? The networking code uses what is called an ioctl (i/o control) call
  3247.   to change the serial devices into SLIP devices. There are two programs
  3248.   supplied that can do this, they are called dip and slattach
  3249.  
  3250.   6.27.1.  dip
  3251.  
  3252.   dip (Dialup IP) is a smart program that is able to set the speed of
  3253.   the serial device, command your modem to dial the remote end of the
  3254.   link, automatically log you into the remote server, search for
  3255.   messages sent to you by the server and extract information for them
  3256.   such as your IP address and perform the ioctl necessary to switch your
  3257.   serial port into SLIP mode. dip has a powerful scripting ability and
  3258.   it is this that you can exploit to automate your logon procedure.
  3259.  
  3260.   You can find it at: sunsite.unc.edu
  3261.   <ftp://sunsite.unc.edu/pub/Linux/system/Network/serial/dip/dip337o-
  3262.   uri.tgz>.
  3263.  
  3264.   To install it, try the following:
  3265.  
  3266.        #
  3267.        # cd /usr/src
  3268.        # gzip -dc dip337o-uri.tgz | tar xvf -
  3269.        # cd dip-3.3.7o
  3270.  
  3271.        <edit Makefile>
  3272.  
  3273.        # make install
  3274.        #
  3275.  
  3276.   The Makefile assumes the existence of a group called uucp, but you
  3277.   might like to change this to either dip or SLIP depending on your
  3278.   configuration.
  3279.  
  3280.   6.27.2.  slattach
  3281.  
  3282.   slattach as contrasted with dip is a very simple program, that is very
  3283.   easy to use, but does not have the sophistication of dip.  It does not
  3284.   have the scripting ability, all it does is configure your serial
  3285.   device as a SLIP device. It assumes you have all the information you
  3286.   need and the serial line is established before you invoke it. slattach
  3287.   is ideal to use where you have a permanent connection to your server,
  3288.   such as a physical cable, or a leased line.
  3289.  
  3290.   6.27.3.  When do I use which ?
  3291.  
  3292.   You would use dip when your link to the machine that is your SLIP
  3293.   server is a dialup modem, or some other temporary link. You would use
  3294.   slattach when you have a leased line, perhaps a cable, between your
  3295.   machine and the server and there is no special action needed to get
  3296.   the link working. See section `Permanent Slip connection' for more
  3297.   information.
  3298.  
  3299.   Configuring SLIP is much like configuring an Ethernet interface (read
  3300.   section `Configuring an ethernet device' above). However there are a
  3301.   few key differences.
  3302.  
  3303.   First of all, SLIP links are unlike ethernet networks in that there is
  3304.   only ever two hosts on the network, one at each end of the link.
  3305.   Unlike an ethernet that is available for use as soon are you are
  3306.   cabled, with SLIP, depending on the type of link you have, you may
  3307.   have to initialize your network connection in some special way.
  3308.  
  3309.   If you are using dip then this would not normally be done at boot
  3310.   time, but at some time later, when you were ready to use the link.  It
  3311.   is possible to automate this procedure. If you are using slattach then
  3312.   you will probably want to add a section to your rc.inet1 file.  This
  3313.   will be described soon.
  3314.  
  3315.   There are two major types of SLIP servers: Dynamic IP address servers
  3316.   and static IP address servers. Almost every SLIP server will prompt
  3317.   you to login using a username and password when dialing in. dip can
  3318.   handle logging you in automatically.
  3319.  
  3320.   6.27.4.  Static SLIP server with a dialup line and DIP.
  3321.  
  3322.   A static SLIP server is one in which you have been supplied an IP
  3323.   address that is exclusively yours. Each time you connect to the
  3324.   server, you will configure your SLIP port with that address. The
  3325.   static SLIP server will answer your modem call, possibly prompt you
  3326.   for a username and password, and then route any datagrams destined for
  3327.   your address to you via that connection. If you have a static server,
  3328.   then you may want to put entries for your hostname and IP address
  3329.   (since you know what it will be) into your /etc/hosts. You should also
  3330.   configure some other files such as: rc.inet2, host.conf, resolv.conf,
  3331.   /etc/HOSTNAME and rc.local. Remember that when configuring rc.inet1,
  3332.   you don't need to add any special commands for your SLIP connection
  3333.   since it is dip that does all of the hard work for you in configuring
  3334.   your interface. You will need to give dip the appropriate information
  3335.   and it will configure the interface for you after commanding the modem
  3336.   to establish the call and logging you into your SLIP server.
  3337.  
  3338.   If this is how your SLIP server works then you can move to section
  3339.   `Using Dip' to learn how to configure dip appropriately.
  3340.  
  3341.   6.27.5.  Dynamic SLIP server with a dialup line and DIP.
  3342.  
  3343.   A dynamic SLIP server is one which allocates you an IP address
  3344.   randomly, from a pool of addresses, each time you logon. This means
  3345.   that there is no guarantee that you will have any particular address
  3346.   each time, and that address may well be used by someone else after you
  3347.   have logged off.  The network administrator who configured the SLIP
  3348.   server will have assigned a pool of address for the SLIP server to
  3349.   use, when the server receives a new incoming call, it finds the first
  3350.   unused address, guides the caller through the login process and then
  3351.   prints a welcome message that contains the IP address it has allocated
  3352.   and will proceed to use that IP address for the duration of that call.
  3353.  
  3354.   Configuring for this type of server is similar to configuring for a
  3355.   static server, except that you must add a step where you obtain the IP
  3356.   address that the server has allocated for you and configure your SLIP
  3357.   device with that.
  3358.  
  3359.   Again, dip does the hard work and new versions are smart enough to not
  3360.   only log you in, but to also be able to automatically read the IP
  3361.   address printed in the welcome message and store it so that you can
  3362.   have it configure your SLIP device with it.
  3363.  
  3364.   If this is how your SLIP server works then you can move to section
  3365.   `Using Dip' to learn how to configure dip appropriately.
  3366.  
  3367.   6.27.6.  Using DIP.
  3368.  
  3369.   As explained earlier, dip is a powerful program that can simplify and
  3370.   automate the process of dialing into the SLIP server, logging you in,
  3371.   starting the connection and configuring your SLIP devices with the
  3372.   appropriate ifconfig and route commands.
  3373.  
  3374.   Essentially to use dip you'll write a `dip script', which is basically
  3375.   a list of commands that dip understands that tell dip how to perform
  3376.   each of the actions you want it to perform. See sample.dip that comes
  3377.   supplied with dip to get an idea of how it works. dip is quite a
  3378.   powerful program, with many options.  Instead of going into all of
  3379.   them here you should look at the man page, README and sample files
  3380.   that will have come with your version of dip.
  3381.  
  3382.   You may notice that the sample.dip script assumes that you're using a
  3383.   static SLIP server, so you know what your IP address is beforehand.
  3384.   For dynamic SLIP servers, the newer versions of dip include a command
  3385.   you can use to automatically read and configure your SLIP device with
  3386.   the IP address that the dynamic server allocates for you. The
  3387.   following sample is a modified version of the sample.dip that came
  3388.   supplied with dip337j-uri.tgz and is probably a good starting point
  3389.   for you.  You might like to save it as /etc/dipscript and edit it to
  3390.   suit your configuration:
  3391.  
  3392.   #
  3393.   # sample.dip    Dialup IP connection support program.
  3394.   #
  3395.   #               This file (should show) shows how to use the DIP
  3396.   #       This file should work for Annex type dynamic servers, if you
  3397.   #       use a static address server then use the sample.dip file that
  3398.   #       comes as part of the dip337-uri.tgz package.
  3399.   #
  3400.   #
  3401.   # Version:      @(#)sample.dip  1.40    07/20/93
  3402.   #
  3403.   # Author:       Fred N. van Kempen, <waltje@uWalt.NL.Mugnet.ORG>
  3404.   #
  3405.  
  3406.   main:
  3407.   # Next, set up the other side's name and address.
  3408.   # My dialin machine is called 'xs4all.hacktic.nl' (== 193.78.33.42)
  3409.   get $remote xs4all.hacktic.nl
  3410.   # Set netmask on sl0 to 255.255.255.0
  3411.   netmask 255.255.255.0
  3412.   # Set the desired serial port and speed.
  3413.   port cua02
  3414.   speed 38400
  3415.  
  3416.   # Reset the modem and terminal line.
  3417.   # This seems to cause trouble for some people!
  3418.   reset
  3419.  
  3420.   # Note! "Standard" pre-defined "errlevel" values:
  3421.   #  0 - OK
  3422.   #  1 - CONNECT
  3423.   #  2 - ERROR
  3424.   #
  3425.   # You can change those grep'ping for "addchat()" in *.c...
  3426.  
  3427.   # Prepare for dialing.
  3428.   send ATQ0V1E1X4\r
  3429.   wait OK 2
  3430.   if $errlvl != 0 goto modem_trouble
  3431.   dial 555-1234567
  3432.   if $errlvl != 1 goto modem_trouble
  3433.  
  3434.   # We are connected.  Login to the system.
  3435.   login:
  3436.   sleep 2
  3437.   wait ogin: 20
  3438.   if $errlvl != 0 goto login_trouble
  3439.   send MYLOGIN\n
  3440.   wait ord: 20
  3441.   if $errlvl != 0 goto password_error
  3442.   send MYPASSWD\n
  3443.   loggedin:
  3444.  
  3445.   # We are now logged in.
  3446.   wait SOMEPROMPT 30
  3447.   if $errlvl != 0 goto prompt_error
  3448.  
  3449.   # Command the server into SLIP mode
  3450.   send SLIP\n
  3451.   wait SLIP 30
  3452.   if $errlvl != 0 goto prompt_error
  3453.  
  3454.   # Get and Set your IP address from the server.
  3455.   #   Here we assume that after commanding the SLIP server into SLIP
  3456.   #   mode that it prints your IP address
  3457.   get $locip remote 30
  3458.   if $errlvl != 0 goto prompt_error
  3459.  
  3460.   # Set up the SLIP operating parameters.
  3461.   get $mtu 296
  3462.   # Ensure "route add -net default xs4all.hacktic.nl" will be done
  3463.   default
  3464.  
  3465.   # Say hello and fire up!
  3466.   done:
  3467.   print CONNECTED $locip ---> $rmtip
  3468.   mode CSLIP
  3469.   goto exit
  3470.  
  3471.   prompt_error:
  3472.   print TIME-OUT waiting for sliplogin to fire up...
  3473.   goto error
  3474.  
  3475.   login_trouble:
  3476.   print Trouble waiting for the Login: prompt...
  3477.   goto error
  3478.  
  3479.   password:error:
  3480.   print Trouble waiting for the Password: prompt...
  3481.   goto error
  3482.  
  3483.   modem_trouble:
  3484.   print Trouble occurred with the modem...
  3485.   error:
  3486.   print CONNECT FAILED to $remote
  3487.   quit
  3488.  
  3489.   exit:
  3490.   exit
  3491.  
  3492.   The above example assumes you are calling a dynamic SLIP server, if
  3493.   you are calling a static SLIP server, then the sample.dip file that
  3494.   comes with dip337j-uri.tgz should work for you.
  3495.  
  3496.   When dip is given the get $local command it searches the incoming text
  3497.   from the remote end for a string that looks like an IP address, ie
  3498.   strings numbers separated by `.' characters. This modification was put
  3499.   in place specifically for dynamic SLIP servers, so that the process of
  3500.   reading the IP address granted by the server could be automated.
  3501.  
  3502.   The example above will automatically create a default route via your
  3503.   SLIP link, if this is not what you want, you might have an ethernet
  3504.   connection that should be your default route, then remove the default
  3505.   command from the script.  After this script has finished running, if
  3506.   you do an ifconfig command, you will see that you have a device sl0.
  3507.   This is your SLIP device.  Should you need to, you can modify its
  3508.   configuration manually, after the dip command has finished, using the
  3509.   ifconfig and route commands.
  3510.  
  3511.   Please note that dip allows you to select a number of different
  3512.   protocols to use with the mode command, the most common example is
  3513.   cSLIP for SLIP with compression. Please note that both ends of the
  3514.   link must agree, so you should ensure that whatever you select agrees
  3515.   with what your server is set to.
  3516.  
  3517.   The above example is fairly robust and should cope with most errors.
  3518.   Please refer to the dip man page for more information. Naturally you
  3519.   could, for example, code the script to do such things as redial the
  3520.   server if it doesn't get a connection within a prescribed period of
  3521.   time, or even try a series of servers if you have access to more than
  3522.   one.
  3523.  
  3524.   6.27.7.  Permanent SLIP connection using a leased line and slattach.
  3525.  
  3526.   If you have a cable between two machines, or are fortunate enough to
  3527.   have a leased line, or some other permanent serial connection between
  3528.   your machine and another, then you don't need to go to all the trouble
  3529.   of using dip to set up your serial link. slattach is a very simple to
  3530.   use utility that will allow you just enough functionality to configure
  3531.   your connection.
  3532.  
  3533.   Since your connection will be a permanent one, you will want to add
  3534.   some commands to your rc.inet1 file. In essence all you need to do for
  3535.   a permanent connection is ensure that you configure the serial device
  3536.   to the correct speed and switch the serial device into SLIP mode.
  3537.   slattach allows you to do this with one command. Add the following to
  3538.   your rc.inet1 file:
  3539.  
  3540.        #
  3541.        # Attach a leased line static SLIP connection
  3542.        #
  3543.        #  configure /dev/cua0 for 19.2kbps and cslip
  3544.        /sbin/slattach -p cslip -s 19200 /dev/cua0 &
  3545.        /sbin/ifconfig sl0 IPA.IPA.IPA.IPA pointopoint IPR.IPR.IPR.IPR up
  3546.        #
  3547.        # End static SLIP.
  3548.  
  3549.   Where:
  3550.  
  3551.      IPA.IPA.IPA.IPA
  3552.         represents your IP address.
  3553.  
  3554.      IPR.IPR.IPR.IPR
  3555.         represents the IP address of the remote end.
  3556.  
  3557.   slattach allocates the first unallocated SLIP device to the serial
  3558.   device specified. slattach starts with sl0. Therefore the first
  3559.   slattach command attaches SLIP device sl0 to the serial device
  3560.   specified and sl1 the next time, etc.
  3561.  
  3562.   slattach allows you to configure a number of different protocols with
  3563.   the -p argument. In your case you will use either SLIP or cSLIP
  3564.   depending on whether you want to use compression or not.  Note: both
  3565.   ends must agree on whether you want compression or not.
  3566.  
  3567.   6.28.  SLIP server.
  3568.  
  3569.   If you have a machine that is perhaps network connected, that you'd
  3570.   like other people be able to dial into and provide network services,
  3571.   then you will need to configure your machine as a server. If you want
  3572.   to use SLIP as the serial line protocol, then currently you have three
  3573.   options as to how to configure your Linux machine as a SLIP server. My
  3574.   preference would be to use the first presented, sliplogin, as it seems
  3575.   the easiest to configure and understand, but I will present a summary
  3576.   of each, so you can make your own decision.
  3577.  
  3578.   6.28.1.  Slip Server using sliplogin.
  3579.  
  3580.   sliplogin is a program that you can use in place of the normal login
  3581.   shell for SLIP users that converts the terminal line into a SLIP line.
  3582.   It allows you to configure your Linux machine as either a static
  3583.   address server, users get the same address everytime they call in, or
  3584.   a dynamic address server, where users get an address allocated for
  3585.   them which will not necessarily be the same as the last time they
  3586.   called.
  3587.  
  3588.   The caller will login as per the standard login process, entering
  3589.   their username and password, but instead of being presented with a
  3590.   shell after their login, sliplogin is executed which searches its
  3591.   configuration file (/etc/slip.hosts) for an entry with a login name
  3592.   that matches that of the caller. If it locates one, it configures the
  3593.   line as an 8bit clean line, and uses an ioctl call to convert the line
  3594.   discipline to SLIP. When this process is complete, the last stage of
  3595.   configuration takes place, where sliplogin invokes a shell script
  3596.   which configures the SLIP interface with the relevant ip address,
  3597.   netmask and sets appropriate routing in place.  This script is usually
  3598.   called /etc/slip.login, but in a similar manner to getty, if you have
  3599.   certain callers that require special initialisation, then you can
  3600.   create configuration scripts called /etc/slip.login.loginname that
  3601.   will be run instead of the default specifically for them.
  3602.  
  3603.   There are either three or four files that you need to configure to get
  3604.   sliplogin working for you. I will detail how and where to get the
  3605.   software and how each is configured in detail. The files are:
  3606.  
  3607.   ╖  /etc/passwd, for the dialin user accounts.
  3608.  
  3609.   ╖  /etc/slip.hosts, to contain the information unique to each dial-in
  3610.      user.
  3611.  
  3612.   ╖  /etc/slip.login, which manages the configuration of the routing
  3613.      that needs to be performed for the user.
  3614.  
  3615.   ╖  /etc/slip.tty, which is required only if you are configuring your
  3616.      server for dynamic address allocation and contains a table of
  3617.      addresses to allocate
  3618.  
  3619.   ╖  /etc/slip.logout, which contains commands to clean up after the
  3620.      user has hung up or logged out.
  3621.  
  3622.   6.28.1.1.  Where to get sliplogin
  3623.  
  3624.   You may already have the sliplogin package installed as part of your
  3625.   distribution, if not then sliplogin can be obtained from:
  3626.   sunsite.unc.edu
  3627.   <ftp://sunsite.unc.edu/pub/linux/system/Network/serial/sliplogin-2.1.1.tar.gz>.
  3628.   The tar file contains both source, precompiled binaries and a man
  3629.   page.
  3630.  
  3631.   To ensure that only authorised users will be able to run sliplogin
  3632.   program, you should add an entry to your /etc/group file similar to
  3633.   the following:
  3634.  
  3635.         ..
  3636.        slip::13:radio,fred
  3637.         ..
  3638.  
  3639.   When you install the sliplogin package, the Makefile will change the
  3640.   group ownership of the sliplogin program to slip, and this will mean
  3641.   that only users who belong to that group will be able to execute it.
  3642.   The example above will allow only users radio and fred to execute
  3643.   sliplogin.
  3644.  
  3645.   To install the binaries into your /sbin directory and the man page
  3646.   into section 8, do the following:
  3647.  
  3648.        # cd /usr/src
  3649.        # gzip -dc .../sliplogin-2.1.1.tar.gz | tar xvf -
  3650.        # cd sliplogin-2.1.1
  3651.        # <..edit the Makefile if you don't use shadow passwords..>
  3652.        # make install
  3653.  
  3654.   If you want to recompile the binaries before installation, add a make
  3655.   clean before the make install. If you want to install the binaries
  3656.   somewhere else, you will need to edit the Makefile install rule.
  3657.  
  3658.   Please read the README files that come with the package for more
  3659.   information.
  3660.  
  3661.   6.28.1.2.  Configuring /etc/passwd for Slip hosts.
  3662.  
  3663.   Normally you would create some special logins for Slip callers in your
  3664.   /etc/passwd file. A convention commonly followed is to use the
  3665.   hostname of the calling host with a capital `S' prefixing it. So, for
  3666.   example, if the calling host is called radio then you could create a
  3667.   /etc/passwd entry that looked like:
  3668.  
  3669.        Sradio:FvKurok73:1427:1:radio SLIP login:/tmp:/sbin/sliplogin
  3670.  
  3671.   It doesn't really matter what the account is called, so long as it is
  3672.   meaningful to you.
  3673.  
  3674.   Note: the caller doesn't need any special home directory, as they will
  3675.   not be presented with a shell from this machine, so /tmp is a good
  3676.   choice.  Also note that sliplogin is used in place of the normal login
  3677.   shell.
  3678.  
  3679.   6.28.1.3.  Configuring /etc/slip.hosts
  3680.  
  3681.   The /etc/slip.hosts file is the file that sliplogin searches for
  3682.   entries matching the login name to obtain configuration details for
  3683.   this caller. It is this file where you specify the ip address and
  3684.   netmask that will be assigned to the caller and configured for their
  3685.   use. Sample entries for two hosts, one a static configuration for host
  3686.   radio and another, a dynamic configuration for user host albert might
  3687.   look like:
  3688.  
  3689.   #
  3690.   Sradio   44.136.8.99   44.136.8.100  255.255.255.0  normal      -1
  3691.   Salbert  44.136.8.99   DYNAMIC       255.255.255.0  compressed  60
  3692.   #
  3693.  
  3694.   The /etc/slip.hosts file entries are:
  3695.  
  3696.   1. the login name of the caller.
  3697.  
  3698.   2. ip address of the server machine, ie this machine.
  3699.  
  3700.   3. ip address that the caller will be assigned. If this field is coded
  3701.      DYNAMIC then an ip address will be allocated based on the
  3702.      information contained in your /etc/slip.tty file discussed later.
  3703.      Note: you must be using at least version 1.3 of sliplogin for this
  3704.      to work.
  3705.  
  3706.   4. the netmask assigned to the calling machine in dotted decimal
  3707.      notation eg 255.255.255.0 for a Class C network mask.
  3708.  
  3709.   5. the slip mode setting which allows you to enable/disable
  3710.      compression and slip other features. Allowable values here are
  3711.      "normal" or "compressed".
  3712.  
  3713.   6. a timeout parameter which specifies how long the line can remain
  3714.      idle (no datagrams received) before the line is automatically
  3715.      disconnected. A negative value disables this feature.
  3716.  
  3717.   7. optional arguments.
  3718.  
  3719.   Note: You can use either hostnames or IP addresses in dotted decimal
  3720.   notation for fields 2 and 3. If you use hostnames then those hosts
  3721.   must be resolvable, that is, your machine must be able to locate an ip
  3722.   address for those hostnames, otherwise the script will fail when it is
  3723.   called. You can test this by trying trying to telnet to the hostname,
  3724.   if you get the `Trying nnn.nnn.nnn...' message then your machine has
  3725.   been able to find an ip address for that name. If you get the message
  3726.   `Unknown host', then it has not. If not, either use ip addresses in
  3727.   dotted decimal notation, or fix up your name resolver configuration
  3728.   (See section Name Resolution).
  3729.  
  3730.   The most common slip modes are:
  3731.  
  3732.      normal
  3733.         to enable normal uncompressed SLIP.
  3734.  
  3735.      compressed
  3736.         to enable van Jacobsen header compression (cSLIP)
  3737.  
  3738.   Naturally these are mutually exclusive, you can use one or the other.
  3739.   For more information on the other options available, refer to the man
  3740.   pages.
  3741.  
  3742.   6.28.1.4.  Configuring the /etc/slip.login file.
  3743.  
  3744.   After sliplogin has searched the /etc/slip.hosts and found a matching
  3745.   entry, it will attempt to execute the /etc/slip.login file to actually
  3746.   configure the SLIP interface with its ip address and netmask.
  3747.  
  3748.   The sample /etc/slip.login file supplied with the sliplogin package
  3749.   looks like this:
  3750.        #!/bin/sh -
  3751.        #
  3752.        #       @(#)slip.login  5.1 (Berkeley) 7/1/90
  3753.        #
  3754.        # generic login file for a SLIP line.  sliplogin invokes this with
  3755.        # the parameters:
  3756.        #     $1       $2       $3    $4, $5, $6 ...
  3757.        #   SLIPunit ttyspeed   pid   the arguments from the slip.host entry
  3758.        #
  3759.        /sbin/ifconfig $1 $5 pointopoint $6 mtu 1500 -trailers up
  3760.        /sbin/route add $6
  3761.        arp -s $6 <hw_addr> pub
  3762.        exit 0
  3763.        #
  3764.  
  3765.   You will note that this script simply uses the ifconfig and route
  3766.   commands to configure the SLIP device with its ipaddress, remote ip
  3767.   address and netmask and creates a route for the remote address via the
  3768.   SLIP device. Just the same as you would if you were using the slattach
  3769.   command.
  3770.  
  3771.   Note also the use of Proxy ARP to ensure that other hosts on the same
  3772.   ethernet as the server machine will know how to reach the dial-in
  3773.   host.  The <hw_addr> field should be the hardware address of the
  3774.   ethernet card in the machine. If your server machine isn't on an
  3775.   ethernet network then you can leave this line out completely.
  3776.  
  3777.   6.28.1.5.  Configuring the /etc/slip.logout file.
  3778.  
  3779.   When the call drops out, you want to ensure that the serial device is
  3780.   restored to its normal state so that future callers will be able to
  3781.   login correctly.  This is achieved with the use of the
  3782.   /etc/slip.logout file. It is quite simple in format and is called with
  3783.   the same argument as the /etc/slip.login file.
  3784.  
  3785.        #!/bin/sh -
  3786.        #
  3787.        #               slip.logout
  3788.        #
  3789.        /sbin/ifconfig $1 down
  3790.        arp -d $6
  3791.        exit 0
  3792.        #
  3793.  
  3794.   All it does is `down' the interface which will delete the manual route
  3795.   previously created. It also uses the arp command to delete any proxy
  3796.   arp put in place, again, you don't need the arp command in the script
  3797.   if your server machine does not have an ethernet port.
  3798.  
  3799.   6.28.1.6.  Configuring the /etc/slip.tty file.
  3800.  
  3801.   If you are using dynamic ip address allocation (have any hosts
  3802.   configured with the DYNAMIC keyword in the /etc/slip.hosts file, then
  3803.   you must configure the /etc/slip.tty file to list what addresses are
  3804.   assigned to what port. You only need this file if you wish your server
  3805.   to dynamically allocate addresses to users.
  3806.   The file is a table that lists the tty devices that will support dial-
  3807.   in SLIP connections and the ip address that should be assigned to
  3808.   users who call in on that port.
  3809.  
  3810.   Its format is as follows:
  3811.  
  3812.        # slip.tty    tty -> IP address mappings for dynamic SLIP
  3813.        # format: /dev/tty?? xxx.xxx.xxx.xxx
  3814.        #
  3815.        /dev/ttyS0      192.168.0.100
  3816.        /dev/ttyS1      192.168.0.101
  3817.        #
  3818.  
  3819.   What this table says is that callers that dial in on port /dev/ttyS0
  3820.   who have their remote address field in the /etc/slip.hosts file set to
  3821.   DYNAMIC will be assigned an address of 192.168.0.100.
  3822.  
  3823.   In this way you need only allocate one address per port for all users
  3824.   who do not require an dedicated address for themselves. This helps you
  3825.   keep the number of addresses you need down to a minimum to avoid
  3826.   wastage.
  3827.  
  3828.   6.28.2.  Slip Server using dip.
  3829.  
  3830.   Let me start by saying that some of the information below came from
  3831.   the dip man pages, where how to run Linux as a SLIP server is briefly
  3832.   documented. Please also beware that the following has been based on
  3833.   the dip337o-uri.tgz package and probably will not apply to other
  3834.   versions of dip.
  3835.  
  3836.   dip has an input mode of operation, where it automatically locates an
  3837.   entry for the user who invoked it and configures the serial line as a
  3838.   SLIP link according to information it finds in the /etc/diphosts file.
  3839.   This input mode of operation is activated by invoking dip as diplogin.
  3840.   This therefore is how you use dip as a SLIP server, by creating
  3841.   special accounts where diplogin is used as the login shell.
  3842.  
  3843.   The first thing you will need to do is to make a symbolic link as
  3844.   follows:
  3845.  
  3846.        # ln -sf /usr/sbin/dip /usr/sbin/diplogin
  3847.  
  3848.   You then need to add entries to both your /etc/passwd and your
  3849.   /etc/diphosts files. The entries you need to make are formatted as
  3850.   follows:
  3851.  
  3852.   To configure Linux as a SLIP server with dip, you need to create some
  3853.   special SLIP accounts for users, where dip (in input mode) is used as
  3854.   the login shell. A suggested convention is that of having all SLIP
  3855.   accounts begin with a capital `S', eg `Sfredm'.
  3856.  
  3857.   A sample /etc/passwd entry for a SLIP user looks like:
  3858.  
  3859.   Sfredm:ij/SMxiTlGVCo:1004:10:Fred:/tmp:/usr/sbin/diplogin
  3860.   ^^         ^^        ^^  ^^   ^^   ^^   ^^
  3861.   |          |         |   |    |    |    \__ diplogin as login shell
  3862.   |          |         |   |    |    \_______ Home directory
  3863.   |          |         |   |    \____________ User Full Name
  3864.   |          |         |   \_________________ User Group ID
  3865.   |          |         \_____________________ User ID
  3866.   |          \_______________________________ Encrypted User Password
  3867.   \__________________________________________ Slip User Login Name
  3868.  
  3869.   After the user logs in, the login program, if it finds and verifies
  3870.   the user ok, will execute the diplogin command. dip, when invoked as
  3871.   diplogin knows that it should automatically assume that it is being
  3872.   used a login shell. When it is started as diplogin the first thing it
  3873.   does is use the getuid() function call to get the userid of whoever
  3874.   has invoked it. It then searches the /etc/diphosts file for the first
  3875.   entry that matches either the userid or the name of the tty device
  3876.   that the call has come in on and configures itself appropriately.  By
  3877.   judicious decision as to whether to give a user an entry in the
  3878.   diphosts file, or whether to let the user be given the default
  3879.   configuration you can build your server in such a way that you can
  3880.   have a mix of static and dynamically assigned address users.
  3881.  
  3882.   dip will automatically add a `Proxy-ARP' entry if invoked in input
  3883.   mode, so you do not need to worry about manually adding such entries.
  3884.  
  3885.   6.28.2.1.  Configuring /etc/diphosts
  3886.  
  3887.   /etc/diphosts is used by dip to lookup preset configurations for
  3888.   remote hosts. These remote hosts might be users dialing into your
  3889.   linux machine, or they might be for machines that you dial into with
  3890.   your linux machine.
  3891.  
  3892.   The general format for /etc/diphosts is as follows:
  3893.  
  3894.         ..
  3895.        Suwalt::145.71.34.1:145.71.34.2:255.255.255.0:SLIP uwalt:CSLIP,1006
  3896.        ttyS1::145.71.34.3:145.71.34.2:255.255.255.0:Dynamic ttyS1:CSLIP,296
  3897.         ..
  3898.  
  3899.   The fields are:
  3900.  
  3901.   1. login name: as returned by getpwuid(getuid()) or tty name.
  3902.  
  3903.   2. unused: compat. with passwd
  3904.  
  3905.   3. Remote Address: IP address of the calling host, either numeric or
  3906.      by name
  3907.  
  3908.   4. Local Address: IP address of this machine, again numeric or by name
  3909.  
  3910.   5. Netmask: in dotted decimal notation
  3911.  
  3912.   6. Comment field: put whatever you want here.
  3913.  
  3914.   7. protocol: Slip, CSlip etc.
  3915.  
  3916.   8. MTU: decimal number
  3917.  
  3918.   An example /etc/net/diphosts entry for a remote SLIP user might be:
  3919.  
  3920.        Sfredm::145.71.34.1:145.71.34.2:255.255.255.0:SLIP uwalt:SLIP,296
  3921.  
  3922.   which specifies a SLIP link with remote address of 145.71.34.1 and MTU
  3923.   of 296, or:
  3924.  
  3925.        Sfredm::145.71.34.1:145.71.34.2:255.255.255.0:SLIP uwalt:CSLIP,1006
  3926.  
  3927.   which specifies a cSLIP-capable link with remote address 145.71.34.1
  3928.   and MTU of 1006.
  3929.  
  3930.   Therefore, all users who you wish to be allowed a statically allocated
  3931.   dial-up IP access should have an entry in the /etc/diphosts. If you
  3932.   want users who call a particular port to have their details
  3933.   dynamically allocated then you must have an entry for the tty device
  3934.   and do not configure a user based entry. You should remember to
  3935.   configure at least one entry for each tty device that your dialup
  3936.   users use to ensure that a suitable configuration is available for
  3937.   them regardless of which modem they call in on.
  3938.  
  3939.   When a user logs in they will receive a normal login and password
  3940.   prompt at which they should enter their SLIP-login userid and
  3941.   password. If these verify ok then the user will see no special
  3942.   messages and they should just change into SLIP mode at their end. The
  3943.   user should then be able to connect ok and be configured with the
  3944.   relevant parameters from the diphosts file.
  3945.  
  3946.   6.28.3.  SLIP server using the dSLIP package.
  3947.  
  3948.   Matt Dillon <dillon@apollo.west.oic.com> has written a package that
  3949.   does not only dial-in but also dial-out SLIP. Matt's package is a
  3950.   combination of small programs and scripts that manage your connections
  3951.   for you. You will need to have tcsh installed as at least one of the
  3952.   scripts requires it. Matt supplies a binary copy of the expect utility
  3953.   as it too is needed by one of the scripts. You will most likely need
  3954.   some experience with expect to get this package working to your
  3955.   liking, but don't let that put you off.
  3956.  
  3957.   Matt has written a good set of installation instructions in the README
  3958.   file, so I won't bother repeating them.
  3959.  
  3960.   You can get the dSLIP package from its home site at:
  3961.  
  3962.   apollo.west.oic.com
  3963.  
  3964.        /pub/linux/dillon_src/dSLIP203.tgz
  3965.  
  3966.   or from:
  3967.  
  3968.   sunsite.unc.edu
  3969.  
  3970.        /pub/Linux/system/Network/serial/dSLIP203.tgz
  3971.  
  3972.   Read the README file and create the /etc/passwd and /etc/group entries
  3973.   before doing a make install.
  3974.  
  3975.   6.29.  STRIP support (Starmode Radio IP)
  3976.  
  3977.   STRIP device names are `st0', `st1', etc.
  3978.  
  3979.   Kernel Compile Options:
  3980.  
  3981.        Network device support  --->
  3982.                [*] Network device support
  3983.                ....
  3984.                [*] Radio network interfaces
  3985.                < > STRIP (Metricom starmode radio IP)
  3986.  
  3987.   STRIP is a protocol designed specifically for a range of Metricom
  3988.   radio modems for a research project being conducted by Stanford
  3989.   University called the MosquitoNet Project
  3990.   <http://mosquitonet.Stanford.EDU/mosquitonet.html>.  There is a lot of
  3991.   interesting reading here, even if you aren't directly interested in
  3992.   the project.
  3993.  
  3994.   The Metricom radios connect to a serial port, employ spread spectrum
  3995.   technology and are typically capable of about 100kbps.  Information on
  3996.   the Metricom radios is available from the: Metricom Web Server
  3997.   <http://www.metricom.com/>.
  3998.  
  3999.   At present the standard network tools and utilities do not support the
  4000.   STRIP driver, so you will have to download some customised tools from
  4001.   the MosquitoNet web server. Details on what software you need is
  4002.   available at the: MosquitoNet STRIP Page
  4003.   <http://mosquitonet.Stanford.EDU/strip.html>.
  4004.  
  4005.   A summary of configuration is that you use a modified slattach program
  4006.   to set the line discipline of a serial tty device to STRIP and then
  4007.   configure the resulting `st[0-9]' device as you would for ethernet
  4008.   with one important exception, for technical reasons STRIP does not
  4009.   support the ARP protocol, so you must manually configure the ARP
  4010.   entries for each of the hosts on your subnet. This shouldn't prove too
  4011.   onerous.
  4012.  
  4013.   6.30.  Token Ring
  4014.  
  4015.   Token ring device names are `tr0', `tr1' etc. Token Ring is an IBM
  4016.   standard LAN protocol that avoids collisions by providing a mechanism
  4017.   that allows only one station on the LAN the right to transmit at a
  4018.   time.  A `token' is held by one station at a time and the station
  4019.   holding the token is the only station allowed to transmit. When it has
  4020.   transmitted its data it passes the token onto the next station. The
  4021.   token loops amongst all active stations, hence the name `Token Ring'.
  4022.   Kernel Compile Options:
  4023.  
  4024.        Network device support  --->
  4025.                [*] Network device support
  4026.                ....
  4027.                [*] Token Ring driver support
  4028.                < > IBM Tropic chipset based adaptor support
  4029.  
  4030.   Configuration of token ring is identical to that of ethernet with the
  4031.   exception of the network device name to configure.
  4032.  
  4033.   6.31.  X.25
  4034.  
  4035.   X.25 is a circuit based packet switching protocol defined by the
  4036.   C.C.I.T.T. (a standards body recognised by Telecommunications
  4037.   companies in most parts of the world). An implementation of X.25 and
  4038.   LAPB are being worked on and recent 2.1.* kernels include the work in
  4039.   progress.
  4040.  
  4041.   Jonathon Naylor jsn@cs.nott.ac.uk is leading the development and a
  4042.   mailing list has been established to discuss Linux X.25 related
  4043.   matters.  To subscribe send a message to: majordomo@vger.rutgers.edu
  4044.   with the text "subscribe linux-x25" in the body of the message.
  4045.  
  4046.   Early versions of the configuration tools may be obtained from
  4047.   Jonathon's ftp site at ftp.cs.nott.ac.uk
  4048.   <ftp://ftp.cs.nott.ac.uk/jsn/>.
  4049.  
  4050.   6.32.  WaveLan Card
  4051.  
  4052.   Wavelan device names are `eth0', `eth1', etc.
  4053.  
  4054.   Kernel Compile Options:
  4055.  
  4056.        Network device support  --->
  4057.                [*] Network device support
  4058.                ....
  4059.                [*] Radio network interfaces
  4060.                ....
  4061.                <*> WaveLAN support
  4062.  
  4063.   The WaveLAN card is a spread spectrum wireless lan card. The card
  4064.   looks very like an ethernet card in practice and is configured in much
  4065.   the same way.
  4066.  
  4067.   You can get information on the Wavelan card from Wavelan.com
  4068.   <http://www.wavelan.com/>.
  4069.  
  4070.   7.  Cables and Cabling
  4071.  
  4072.   Those of you handy with a soldering iron may want to build your own
  4073.   cables to interconnect two linux machines. The following cabling
  4074.   diagrams should assist you in this.
  4075.  
  4076.   7.1.  Serial NULL Modem cable
  4077.  
  4078.   Not all NULL modem cables are alike. Many null modem cables do little
  4079.   more than trick your computer into thinking all the appropriate
  4080.   signals are present and swap transmit and receive data. This is ok but
  4081.   means that you must use software flow control (XON/XOFF) which is less
  4082.   efficient than hardware flow control. The following cable provides the
  4083.   best possible signalling between machines and allows you to use
  4084.   hardware (RTS/CTS) flow control.
  4085.  
  4086.        Pin Name  Pin                               Pin
  4087.        Tx Data    2  -----------------------------  3
  4088.        Rx Data    3  -----------------------------  2
  4089.        RTS        4  -----------------------------  5
  4090.        CTS        5  -----------------------------  4
  4091.        Ground     7  -----------------------------  7
  4092.        DTR        20 -\---------------------------  8
  4093.        DSR        6  -/
  4094.        RLSD/DCD   8  ---------------------------/-  20
  4095.                                                 \-  6
  4096.  
  4097.   7.2.  Parallel port cable (PLIP cable)
  4098.  
  4099.   If you intend to use the PLIP protocol between two machines then this
  4100.   cable will work for you irrespective of what sort of parallel ports
  4101.   you have installed.
  4102.  
  4103.        Pin Name    pin            pin
  4104.        STROBE      1*
  4105.        D0->ERROR   2  ----------- 15
  4106.        D1->SLCT    3  ----------- 13
  4107.        D2->PAPOUT  4  ----------- 12
  4108.        D3->ACK     5  ----------- 10
  4109.        D4->BUSY    6  ----------- 11
  4110.        D5          7*
  4111.        D6          8*
  4112.        D7          9*
  4113.        ACK->D3     10 ----------- 5
  4114.        BUSY->D4    11 ----------- 6
  4115.        PAPOUT->D2  12 ----------- 4
  4116.        SLCT->D1    13 ----------- 3
  4117.        FEED        14*
  4118.        ERROR->D0   15 ----------- 2
  4119.        INIT        16*
  4120.        SLCTIN      17*
  4121.        GROUND      25 ----------- 25
  4122.  
  4123.   Notes:
  4124.  
  4125.   ╖  Do not connect the pins marked with an asterisk `*'.
  4126.  
  4127.   ╖  Extra grounds are 18,19,20,21,22,23 and 24.
  4128.  
  4129.   ╖  If the cable you are using has a metallic shield, it should be
  4130.      connected to the metallic DB-25 shell at one end only.
  4131.  
  4132.      Warning: A miswired PLIP cable can destroy your controller card. Be
  4133.      very careful and double check every connection to ensure you don't
  4134.      cause yourself any unnecessary work or heartache.
  4135.  
  4136.   While you may be able to run PLIP cables for long distances, you
  4137.   should avoid it if you can. The specifications for the cable allow for
  4138.   a cable length of about 1 metre or so. Please be very careful when
  4139.   running long plip cables as sources of strong electromagnetic fields
  4140.   such as lightning, power lines and radio transmitters can interfere
  4141.   with and sometimes even damage your controller. If you really want to
  4142.   connect two of your computers over a large distance you really should
  4143.   be looking at obtaining a pair of thin-net ethernet cards and running
  4144.   some coaxial cable.
  4145.  
  4146.   7.3.  10base2 (thin coax) Ethernet Cabling
  4147.  
  4148.   10base2 is an ethernet cabling standard that specifies the use of 52
  4149.   ohm coaxial cable with a diameter of about 5 millimetres. There are a
  4150.   couple of important rules to remember when interconnecting machines
  4151.   with 10base2 cabling.  The first is that you must use terminators at
  4152.   both ends of the cabling.  A terminator is a 52 ohm resistor that
  4153.   helps to ensure that the signal is absorbed and not reflected when it
  4154.   reaches the end of the cable. Without a terminator at each end of the
  4155.   cabling you may find that the ethernet is unreliable or doesn't work
  4156.   at all. Normally you'd use `T pieces' to interconnect the machines, so
  4157.   that you end up with something that looks like:
  4158.  
  4159.         |==========T=============T=============T==========T==========|
  4160.                    |             |             |          |
  4161.                    |             |             |          |
  4162.                  -----         -----         -----      -----
  4163.                  |   |         |   |         |   |      |   |
  4164.                  -----         -----         -----      -----
  4165.  
  4166.   where the `|' at either end represents a terminator, the `======' rep¡
  4167.   resents a length of coaxial cable with BNC plugs at either end and the
  4168.   `T' represents a `T piece' connector. You should keep the length of
  4169.   cable between the `T piece' and the actual ethernet card in the PC as
  4170.   short as possible, ideally the `T piece' will be plugged directly into
  4171.   the ethernet card.
  4172.  
  4173.   7.4.  Twisted Pair Ethernet Cable
  4174.  
  4175.   If you have only two twisted pair ethernet cards and you wish to
  4176.   connect them you do not require a hub. You can cable the two cards
  4177.   directly together.  A diagram showing how to do this is included in
  4178.   the Ethernet-HOWTO <Ethernet-HOWTO.html>
  4179.  
  4180.   8.  Glossary of Terms used in this document.
  4181.  
  4182.   The following is a list of some of the most important terms used in
  4183.   this document.
  4184.  
  4185.      ARP
  4186.         This is an acronym for the Address Resolution Protocol and this
  4187.         is how a network machine associates an IP Address with a
  4188.         hardware address.
  4189.  
  4190.      ATM
  4191.         This is an acronym for Asynchronous Transfer Mode.  An ATM
  4192.         network packages data into standard size blocks which it can
  4193.         convey efficiently from point to point. ATM is a circuit
  4194.         switched packet network technology.
  4195.  
  4196.      client
  4197.         This is usually the piece of software at the end of a system
  4198.         where the user is. There are exceptions to this, for example, in
  4199.         the X11 window system it is actually the server with the user
  4200.         and the client runs on the remote machine. The client is the
  4201.         program or end of a system that is receiving the service
  4202.         provided by the server. In the case of peer to peer systems such
  4203.         as slip or ppp the client is taken to be the end that initiates
  4204.         the connection and the remote end, being called, is taken to be
  4205.         the server.
  4206.  
  4207.      datagram
  4208.         A datagram is a discrete package of data and headers which
  4209.         contain addresses, which is the basic unit of transmission
  4210.         across an IP network. You might also hear this called a
  4211.         `packet'.
  4212.  
  4213.      DLCI
  4214.         The DLCI is the Data Link Connection Identifier and is used to
  4215.         identify a unique virtual point to point connection via a Frame
  4216.         Relay network. The DLCI's are normally assigned by the Frame
  4217.         Relay network provider.
  4218.  
  4219.      Frame Relay
  4220.         Frame Relay is a network technology ideally suited to carrying
  4221.         traffic that is of bursty or sporadic nature. Network costs are
  4222.         reduced by having many Frame Relay customer sharing the same
  4223.         network capacity and relying on them wanting to make use of the
  4224.         network at slightly different times.
  4225.  
  4226.      Hardware address
  4227.         This is a number that uniquely identifies a host in a physical
  4228.         network at the media access layer. Examples of this are Ethernet
  4229.         Addresses and AX.25 Addresses.
  4230.  
  4231.      ISDN
  4232.         This is an acronym for Integrated Services Digital Network. ISDN
  4233.         provides a standardised means by which Telecommunications
  4234.         companies may deliver either voice or data information to a
  4235.         customers premises.  Technically ISDN is a circuit switched data
  4236.         network.
  4237.  
  4238.      ISP
  4239.         This is an acronym of Internet Service Provider. These are
  4240.         organisations or companies that provide people with network
  4241.         connectivity to the Internet.
  4242.  
  4243.      IP address
  4244.         This is a number that uniquely identifies a TCP/IP host on the
  4245.         network. The address is 4 bytes long and is usually represented
  4246.         in what is called the "dotted decimal notation", where each byte
  4247.         is represented in decimal from with dots `.' between them.
  4248.  
  4249.      MSS
  4250.         The Maximum Segment Size (MSS) is the largest quantity of data
  4251.         that can be transmitted at one time. If you want to prevent
  4252.         local fragmentation MSS would equal MTU-IP header.
  4253.  
  4254.      MTU
  4255.         The Maximum Transmission Unit (MTU) is a parameter that
  4256.         determines the largest datagram than can be transmitted by an IP
  4257.         interface without it needing to be broken down into smaller
  4258.         units. The MTU should be larger than the largest datagram you
  4259.         wish to transmit unfragmented. Note, this only prevents
  4260.         fragmentation locally, some other link in the path may have a
  4261.         smaller MTU and the datagram will be fragmented there. Typical
  4262.         values are 1500 bytes for an ethernet interface, or 576 bytes
  4263.         for a SLIP interface.
  4264.  
  4265.      route
  4266.         The route is the path that your datagrams take through the
  4267.         network to reach their destination.
  4268.  
  4269.      server
  4270.         This is usually the piece of software or end of a system remote
  4271.         from the user. The server provides some service to one or many
  4272.         clients.  Examples of servers include ftp, Networked File
  4273.         System, or Domain Name Server. In the case of peer to peer
  4274.         systems such as slip or ppp the server is taken to be the end of
  4275.         the link that is called and the end calling is taken to be the
  4276.         client.
  4277.  
  4278.      window
  4279.         The window is the largest amount of data that the receiving end
  4280.         can accept at a given point in time.
  4281.  
  4282.   9.  Linux for an ISP ?
  4283.  
  4284.   If you are interested in using Linux for ISP purposes the I recommend
  4285.   you take a look at the Linux ISP homepage
  4286.   <http://www.anime.net/linuxisp/> for a good list of pointers to
  4287.   information you might need and use.
  4288.  
  4289.   10.  Acknowledgements
  4290.  
  4291.   I'd like to thank the following people for their contributions to this
  4292.   document (in no particular order): Axel Boldt, Arnt Gulbrandsen, Gary
  4293.   Allpike, Cees de Groot, Alan Cox, Jonathon Naylor, Claes Ensson, Ron
  4294.   Nessim, John Minack, Jean-Pierre Cocatrix, Erez Strauss.
  4295.  
  4296.   A special thanks to Alessandro Rubini for his excellent feedback and
  4297.   contributed corrections.
  4298.  
  4299.   11.  Copyright.
  4300.  
  4301.   The NET-3-HOWTO, information on how to install and configure
  4302.   networking support for Linux. Copyright (c) 1997 Terry Dawson.
  4303.  
  4304.   This program is free software; you can redistribute it and/or modify
  4305.   it under the terms of the GNU General Public License as published by
  4306.   the Free Software Foundation; either version 2 of the License, or (at
  4307.   your option) any later version.
  4308.  
  4309.   This program is distributed in the hope that it will be useful, but
  4310.   WITHOUT ANY WARRANTY; without even the implied warranty of
  4311.   MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
  4312.   General Public License for more details.
  4313.  
  4314.   You should have received a copy of the GNU General Public License
  4315.   along with this program; if not, write to the:
  4316.  
  4317.   Free Software Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139,
  4318.   USA.
  4319.  
  4320.